nickclifton (nickclifton) wrote,

Novemeber 2012 GNU Toolchain Update

Hi Guys,

  One month on and the GCC sources are now in a lot better shape.  The cause for most of the problems last month was that a new register allocator pass has been brought in to GCC.  This pass - LRA or Local Register Allocator - is meant to be simpler, easier to debug, and provide a better job of register allocation.   It is still rather new however, which is why there were so many problems last month.  A lot of these have been sorted out now, which is good news as the 4.8 branch will be happening soon.

  A paper describing the LRA pass was presented at the GNU Tools Cauldron this year, and you can find a copy of it here:

  Another tool that was presented at the GNU Tools Cauldron and which has now made it into the official GCC sources is Google's Address Sanitizer:

  This is a memory error detector that is enabled via the new -faddress-sanitizer command line option.  It augments memory access instructions in order to detect use-after-free and out-of-bound accesses to objects on the heap. 

  There are a couple of new warning options as well:

  This is a C++ warning which triggers if a subobject has an abi_tag attribute that the complete object type does not have.  ABI tags are used to annotate functions and classes where the ABI that the implementation has changed.  So if a tag is applied to a component of an object, but not also applied to the entire class then problems can still arise.


  This issues a warning when a function returns a pointer (or in C++, a reference) to a variable that goes out of scope after the function returns.  This warning is actually enabled by default, so the only real use of the command line option is its inverse.  Ie:

  A couple of minor new features have also been added:

  This tells the compiler that when the preprocessor is running it should not change system header paths by expanding symbolic links, or resolving references to "../" and "./".


  In C++, accept imaginary, fixed-point, or machine-defined literal number suffixes as GNU extensions.  When this option is turned off these suffixes are treated as C++11 user-defined literal numeric suffixes.  This is on by default for all pre-C++11 dialects and all GNU dialects, but off by default for ISO C++11 onwards (option -std=c++11).

  This tells the compiler driver to separate as much dwarf debugging information as possible into a separate output file with the extension .dwo.  This option allows the build system to avoid linking files with debug information.  To be useful, this option requires a debugger capable of reading .dwo files.

  This was already possible using explicit linker and objcopy command lines, but this feature allows the process to be automated by the gcc compiler driver.
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 1 comment