LWN.net Logo

The Gnu Compiler Collection, Version 3.4

April 28, 2004

This article was contributed by Caleb Tennis

The GCC team announced the release of the 3.4 version of the popular Gnu Compiler Collection last week. A list of changes is available here.

As with other releases, this GCC series may cause compilation errors with code that previously built without problems. Many users have been reporting build problems against the new version for some time now, in the hope of having compilation issues addressed prior to the release. Bleeding edge Gentoo users, for example, have been tracking packages and notifying the upstream authors for months. But plenty of issues will continue to go unnoticed, creating hurdles for users to deal with after performing the upgrade.

This release does provide some much anticipated improvements. The C/Objective C/C++ compilers now support precompiled headers (PCH), these can speed up compilation time. The new feature is still considered a technology preview; open source projects with notoriously long compile times, however, are quite eager for the speed boost. One condition, however, stands out in the manual:

Only one precompiled header can be used in a particular compilation.

This condition implies that a source file which includes multiple header files will only benefit from the precompiled support for exactly one of those headers. The workaround for this is to create a monolithic header file which includes all other header files, and use only this header file from within the source. The dependency chain becomes more complicated as a result. While this condition is not ideal, authors may find that the compilation speed improvements are worth the time to change the source.

Also of note for this release: A new compilation scheme, called unit-at-a-time, has been introduced. With this system, the code in a file is parsed first, then optimized later. This allows for better performance by removing unused variables and reordering functions. The changes page notes a 1.3% improvement for the SPECint2000 benchmark on the i386 architecture. Some programs, especially those with inline assembly, may run into problems with this optimizer, some modification to the source code may be required.

Other notable changes in GCC 3.4 include many bug fixes, and enhancements for the Ada, Java, and Fortran front ends. The release also includes improvements for non x86 architectures, and changes to G++ which bring it significantly closer to the ISO/ANSI C++ standard.

Very informal compilation tests were conducted on packages known for their lengthy compilation times to observe what kind of "out-of-the-box" performance enhancements could be seen. The tests were performed on a 2.6GHz P4 running Linux 2.6.4 kernel, the compiler optimization level was set to -O2.

Package GCC 3.3.3 GCC 3.4.0
(without PCH)
GCC 3.4.0
(with PCH)
kdelibs-3.2.2 47:21 44:39 no data
qt-3.3.2 47:05 43:53 34:40
perl-5.8.4 2:19 2:20 no data
gtk+-2.4.0 4:45 4:15 no data

The test results indicate that GCC 3.4 usually provides a significantly faster compile time, particularly when used with PCH support.

Whether the constraint of one PCH per source file continues is up for debate due to the complexity of further implementation and alternatives that have been proposed. It is clear, though, that between optimizations, bugfixes, and PCH support, the GCC team has brought us another great release.


(Log in to post comments)

The Gnu Compiler Collection, Version 3.4

Posted Apr 29, 2004 4:05 UTC (Thu) by ncm (subscriber, #165) [Link]

Two immediate remarks: First, programs and libraries that do a lot of pointer casting will probably need to add "-fno-strict-aliasing" to their CFLAGS settings, or suffer mysterious bugs. Second, the iostreams in the new libstdc++ are enormously faster than in previous releases, thanks largely to an enormous amount of work by Paolo Carlini, Petur Runolfsson, and Jerry Quinn.

The Gnu Compiler Collection, Version 3.4

Posted Apr 29, 2004 5:17 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

Programs that violate ISO C aliasing rules are likely to break with earlier GCC releases as well.

Status of C99 features in GCC 3.4

Posted Apr 29, 2004 17:04 UTC (Thu) by tjc (subscriber, #137) [Link]

It does not appear that the status of C99 features has changed between GCC 3.3 and 3.4. In particular, variable-length arrays are still listed as broken.

http://gcc.gnu.org/gcc-3.4/c99status.html

The Gnu Compiler Collection, Version 3.4

Posted May 6, 2004 7:18 UTC (Thu) by joib (guest, #8541) [Link]

Only one precompiled header can be used in a particular compilation. This condition implies that a source file which includes multiple header files will only benefit from the precompiled support for exactly one of those headers. The workaround for this is to create a monolithic header file which includes all other header files, and use only this header file from within the source.

This sort of breaks the simple rule that "include files should never include include files", found IMHO for good reasons in many style guides.

The Gnu Compiler Collection, Version 3.4

Posted May 7, 2004 18:43 UTC (Fri) by nobrowser (guest, #21196) [Link]

What are the good reasons?

In my own style, every header file is self-contained, #include-ing any other
headers that declare types and macros it mentions. This way people who edit
the top source file are free from worrying about the order of #include-s.

I dislike the idea of a single monolithic header file too, though, for a
different reason: it introduces unneeded dependencies. If you include the
monolithic header in all C files, and then modify _any_ header whatsoever,
everything will be recompiled.

Acutally, that's only true if you generate the dependencies automatically.
If you can keep the details of which source depends on which header and
maintain Makefiles manually you're fine. Still a headache, though.

The Gnu Compiler Collection, Version 3.4

Posted May 9, 2004 22:40 UTC (Sun) by alextingle (guest, #20593) [Link]

When lots of header files refer to one another, large project builds tend to become unmanagable. One change to a single header file can force the recompilation of hundreds of objects. This can slow development to a crawl.

The preferred alternative is to use forward declarations where possible in the header file itself, and put the #include in the body file.

Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds