GCC reaches the 4.4.0 release [LWN.net]

By Forrest Cook
April 21, 2009

The Gnu Compiler Collection (GCC) is likely the most popular compiler that runs under Linux: "The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Java, and Ada, as well as libraries for these languages (libstdc++, libgcj,...)." The GCC project has announced the release of GCC version 4.4.0. "This release is a major release, containing new features (as well as many other improvements) relative to GCC 4.3.x." It also marks the first version in the GCC 4.4 release series.

The changes document details the many modifications that have been made for this new branch.

Some of the broader changes in version 4.4.0 include a number of improvements to the optimizer, the following new command line switches have been added:

-findirect-inlining: makes inliner inline indirect calls that have known targets.
-ftree-switch-conversion: if possible, turns simple initializations of scalar variables in switch statements into static array initializations.
-ftree-builtin-call-dce: eliminates unnecessary calls to some builtin functions when the return value is not used.
-fconserve-stack: minimizes stack usage even at the expense of slower code.
-fno-dwarf2-cfi-asm: tells the assembler to ignore .cfi directives.

Also, the Graphite branch has been merged. Graphite (Gimple Represented as Polyhedra) is a framework for high-level loop optimizations that uses the polyhedral model. GCC now includes C, C++, and Fortran support for version 3.0 of OpenMP, an API specification for parallel programming. New warning command line options include

-Wframe-larger-than=NUMBER: warn if any stack frame is larger than NUMBER bytes.
-Wno-mudflap: disable warnings about constructs which can not be instrumented when using -fmudflap.

C language improvements include:

a new optimize attribute allows setting the optimize level on a per-function basis.
uninitialized warnings now work without enabling optimizations.
-Wparentheses can now warn about expressions such as (!x | y).
-Wsequence-points can now warn within if, while, do while and for blocks.
The new -dU option allows preprocessor macro definitions to be dumped.

C++ language improvements include:

experimental ISO C++0x standard support has been added.
-fdiagnostics-show-option reports errors that can be downgraded to warnings via -fpermissive.
-Wconversion has improved warnings for invalid enumeral types.
-Wuninitialized has improved warnings for non-static reference and const ants for classes without constructors.
value-initialization has been improved for objects with an empty initializer.

FORTRAN language improvements include:

The libcpp preprocessor is now built-in and available by default.
The new -Warray-temporaries option is available for warning about array temporaries.
The new -fcheck-array-temporaries option notifies when an array temporary had to be created.
The DWARF debugging model symbol generation has been improved.
Intrinsics now default to external declarations.
The new -falign-commons flag is available for aligning variables in COMMON blocks.
Fortran 2003 support has been extended.
Fortran 2008 support has been added.

libstdc++ Runtime Library improvements include:

experimental support has been added for non-standard pointer types in containers.
libstdc++ bug 30928 (add casts to libc overloads) has been fixed for targets running glibc 2.10 or later.
Many other bugs have been fixed, especially in <locale>.

Target-specific improvements include:

ARM: support is added for three new processors as well as other improvements.
AVR: support has been added for 25 new devices.
IA-32/x86-64: support has been added for more built-in functions, better optimization and float128.
M68K/ColdFire: adds instruction scheduling support and more.
MIPS: includes efficiency improvements, new options, and support for several new processors.
picochip: an initial C-only language port has been done.
Power Architecture and PowerPC: support for several new processors has been added.
S/390, zSeries and System z9/z10: includes support for a new processor.

The GCC project continues to keep up with the changing processor landscape and new language standards as they evolve. Meanwhile, GCC progress marches on, as documented in the GCC 4.4.1 and GCC 4.5.0 status reports.

(Log in to post comments)

GCC reaches the 4.4.0 release

Posted Apr 23, 2009 18:47 UTC (Thu) by ssam (subscriber, #46587) [Link]

g77 has be replaced by gfortran (several releases ago).

gfortran can compile code written in fortran 77.

GCC reaches the 4.4.0 release

Posted Apr 24, 2009 4:09 UTC (Fri) by jordanb (guest, #45668) [Link]

I'm aware that g77 is no longer supported. I was making a wise-ass statement about LWN's archaic reference to 'FORTRAN' rather than 'Fortran', which is the form preferred since the Fortran 90 standard (about 19 years now).

GCC reaches the 4.4.0 release

Posted Apr 28, 2009 19:39 UTC (Tue) by vmole (guest, #111) [Link]

Those of us who learned to program FORTRAN by punching little holes in paper cards are unlikely to change.

GCC reaches the 4.4.0 release

Posted Apr 24, 2009 10:08 UTC (Fri) by nix (subscriber, #2304) [Link]

I'm afraid this article wasn't as good as it could have been :((

What we got was a compaction of part of the release notes, which you'd
already linked to: anyone interested could have read them anyway.

But what I'm interested in is things not mentioned there:

- the caveats. This is the only GCC release that I can remember that
breaks enough existing code that a separate page of caveats is needed. The
code it breaks is already buggy, but nonetheless...

- graphite and/or the IRA. These are *large* optimizer improvements, with
visible effects on users: graphite drags in some interesting runtime
dependencies on packages that people are very unlikely to have installed
already, and uses Presburger arithmetic (famed for insane time
complexities wherever proof theorists gather in large numbers). What
effect does this little bugger have on compilation and runtime speed? (The
mailing lists probably already contain the answers to this.) The IRA has
not only an unfortunately-chosen acronym that trips up UK and Eire
residents whenever they read it, but also makes major changes to the
register allocator, which is one of the largest things slowing GCC down on
register-starved platforms like i386. What effect does *this* have on
runtime speed?

I can't see how anyone planning to use GCC 4.4 for serious work wouldn't
want to know the answers to these questions, really...

And now... drumroll please... The great answer!!! It is: YMMV

Posted Apr 24, 2009 20:53 UTC (Fri) by khim (subscriber, #9252) [Link]

- graphite and/or the IRA. What effect does this little bugger have on compilation and runtime speed?

The answer is simple: measure and see. IRA usually is able to allocate registers better but graphite often creates additional register pressure. The end result... is mixed. On average gcc 4.4 is better than previous versions of GCC, but some code produces nasty regressions - when loops optimizations introduce so many variables that even IRA can not cope. This is not a big problem on x86-64, but with register-starved architectures (and there are not one but two of then in wide use: IA32 and ARM-Thumb) the only answer is YMMV. Check and see.

I can't see how anyone planning to use GCC 4.4 for serious work wouldn't want to know the answers to these questions, really...

If you plan to use GCC 4.4 for serious work you must grab it and check for yourself. Most programs benefit from GCC 4.4 improvements to one degree or another, but some show regressions. No article can replace real-world tests, sorry...

And now... drumroll please... The great answer!!! It is: YMMV

Posted Apr 25, 2009 10:04 UTC (Sat) by nix (subscriber, #2304) [Link]

I know 'measure and see', but the point of an article like this is usually
to collate things like that which others have already done so that we can
get an idea of the magnitude of the benefit *before* we download it. No
article can replace real-world tests, but it could at least report on a
few of them.

You've provided me with more of a clue than the article :) I was wondering
how the 'early optimizers have no understanding of register pressure'
problem had affected this: I know it was part of the design intent of IRA
to try to make this problem less severe...

GCC reaches the 4.4.0 release

Posted Apr 25, 2009 4:03 UTC (Sat) by dirtyepic (subscriber, #30178) [Link]

- the caveats. This is the only GCC release that I can remember that breaks enough existing code that a separate page of caveats is needed. The code it breaks is already buggy, but nonetheless...

You must have missed the Porting To page of the GCC 4.3 release notes then. :)

At least in my experience, the C++ header cleanup in 4.3 was responsible for a _lot_ more breakage than anything in 4.4 has thrown our way so far. (though the night is still young)

GCC reaches the 4.4.0 release

Posted Apr 25, 2009 10:09 UTC (Sat) by nix (subscriber, #2304) [Link]

Less 'missed' more 'forgot that it wasn't in the release notes as its own
page'.

And, yes, I too suspect this will be much much less painful. But it's
still worthy of note.