GCC 4.6

[bearophile]

They keep adding more and more stuff to GCC, some unfinished notes about GCC 4.6, there are some interesting things:

http://gcc.gnu.org/gcc-4.6/changes.html


Some points:

> Improved auto-detection of const and pure functions. Newly, noreturn functions are auto-detected.

-Wsuggest-attribute=[pure|const|noreturn]
    Warn for cases where adding an attribute may be beneficial. The attributes currently supported are listed below.

    -Wsuggest-attribute=pure
    -Wsuggest-attribute=const
    -Wsuggest-attribute=noreturn
        Warn about functions which might be candidates for attributes pure, const or noreturn. The compiler only warns for functions visible in other compilation units or (in the case of pure and const) if it cannot prove that the function returns normally. A function returns normally if it doesn't contain an infinite loop nor returns abnormally by throwing, calling abort() or trapping. This analysis requires option -fipa-pure-const, which is enabled by default at -O and higher. Higher optimization levels improve the accuracy of the analysis. 


This is one of the "compiler tips" for DMD I was talking about :-) It seems GCC devs like that idea.

It may be good to have a DMD tip that lists where the programmer may add pure, const for class/struct methods, maybe nothrow (and @noreturn if and when it's present in D). It reduces the time needed to add those attributes to D code.

----------------------

> Partial inlining is now supported and enabled by default at -O2 and greater. The feature can
> be controlled via -fpartial-inlining.
> Partial inlining splits functions with short hot path to return. This allows more aggressive
> inlining of the hot path leading to better performance and often to code size reductions
> (because cold parts of functions are not duplicated).

This is very good. The JavaVM is doing this for years. I don't know how GCC finds the hot paths, I presume it uses profiling data.

----------------------

> Virtual methods considered for inlining when caller is inlined and devirtualization
> is possible then.

This is good if it works. I will need to test how well this works...

----------------------

> A new switch -fstack-usage has been added. It makes the compiler output stack
> usage information for the program, on a per-function basis, in an auxiliary file.

This is useful especially on small systems.

----------------------

> The -Wshadow option now warns if a local variable or type declaration shadows another
> type in C++. Note that the compiler will not warn if a local variable shadows a
> struct/class/enum, but will warn if it shadows an explicit typedef.

This seems interesting.

----------------------

> The new -fsplit-stack option permits programs to use a discontiguous stack.
> This is useful for threaded programs, in that it is no longer necessary to specify
> the maximum stack size when creating a thread. This feature is currently only
> implemented for 32-bit and 64-bit x86 GNU/Linux targets.

This sounds like a similar feature of the Go language.

Bye,
bearophile