ImperialViolet

Well, the first set of patches for GCC 3.5 have gone into the mm kernel tree so we can start looking forward to the release of 3.4 soon.

The change log is here, and I'd like to highlight a few points:

Firstly, precompiled headers. This could be a huge gain for large compile runs (KDE anyone?). Basically the compiler can preprocess C/C++ headers and so not have to repeatedly compile them for each unit (read .c or .cc file). Quoting from a snapshot gcc manual (raw texi docs):

To create a precompiled header file, simply compile it as you would any other file, if necessary using the @option{-x} option to make the driver treat it as a C or C++ header file. You will probably want to use a tool like @command{make} to keep the precompiled header up-to-date when the headers it contains change.

A precompiled header file will be searched for when @code{#include} is seen in the compilation. As it searches for the included file (@pxref{Search Path,,Search Path,cpp,The C Preprocessor}) the compiler looks for a precompiled header in each directory just before it looks for the include file in that directory. The name searched for is the name specified in the @code{#include} with @samp{.gch} appended. If the precompiled header file can't be used, it is ignored.

For instance, if you have @code{#include "all.h"}, and you have @file{all.h.gch} in the same directory as @file{all.h}, then the precompiled header file will be used if possible, and the original header will be used otherwise.

If you need to precompile the same header file for different languages, targets, or compiler options, you can instead make a @emph{directory} named like @file{all.h.gch}, and put each precompiled header in the directory. (It doesn't matter what you call the files in the directory, every precompiled header in the directory will be considered.) The first precompiled header encountered in the directory that is valid for this compilation will be used; they're searched in no particular order.

A precompiled header can't be used once the first C token is seen. You can have preprocessor directives before a precompiled header; you can even include a precompiled header from inside another header, so long as there are no C tokens before the @code{#include}.

The precompiled header file must be produced by the same compiler version and configuration as the current compilation is using. The easiest way to guarantee this is to use the same compiler binary for creating and using precompiled headers.

Any macros defined before the precompiled header (including with @option{-D}) must either be defined in the same way as when the precompiled header was generated, or must not affect the precompiled header, which usually means that the they don't appear in the precompiled header at all.

Next up, several GCCisms have been removed. This is a shame as I've been known to use the first two of these in some code (that, frankly, wasn't portable anyway).

• cast-as-lvalue: (char) i = 5;
• conditional-expression-as-lvalue: (a ? b : c) = 2;
• compound-expression-as-lvalue: (a, b) = 2;

(maybe the C standard will include these someday. Unfortunately, the GCC people don't give a rational for removing them.)

We also have a new unit-at-a-time compilation system for C. This allows inter-procedural optimisations. This is mostly useful for optimising static functions as GCC can now change the calling-convention for these and so forth.

And we have make profiledbootstrap which uses the profile-feedback code from 3.3 (which is much improved in 3.4) when building the compiler. GCC claims "an 11% speedup on -O0 and a 7.5% speedup on -O2" (i386, building C++).

Now, the question is, am I brave enough to run a snapshot? Probably not I'm afraid.