GCC 3.4.0 Released

AaronW writes "While checking the GCC website I saw that GCC version 3.4 was officially released on April 18th. Version 3.4 includes numerous changes and enhancements, including better optimization, and the ability to build a profiled version of gcc which is 7.5-11% faster on i386 hardware. Be kind and please use one of the mirror sites."

Comments

Not officially released yet

[RML]

This announcement is premature, it's still propagating to mirrors; the "announcment" is an error. The official release will be tomorrow.

Re:GCJ

[thufir]

It works nicely with SWT.

Take the fact that redhat compiled eclipse itself using gcj. You can get the RPM off their website somewhere.

Thanks

[Markus Registrada]

I don't know about the other bundled compilers, but the 3.4 C++ compiler and library are the best ever in Gcc, by far.

If you run across them, be sure to thank Paolo Carlini, Petur Runolfsson, and Jerry Quinn for making 3.4 iostreams as fast as (and often faster than) Glibc's stdio. Thank them, too for making filebuf support large files (>2G) natively without any code or build changes needed, on any target that allows them.

Worth noting, too, is that this is the first release in which the library is part of the ABI. Every previous release since 2.95 has had to increment the libstdc++.so version number, but future 3.4 (and maybe 3.5) releases should be backward compatible. Ask your distribution maintainers to ship 3.4-built versions of all C++ libraries they package, so that they will be compatible with programs built with this and future releases.

Re:Thanks

[Euphonious Coward]

how ... do iostream's go faster than glibc's fstreams, when the iostreams ultimately _call_ the f*() functions?

Simple: they don't. They call read() and write(), and do their own buffering. Even if they did use fread() and fwrite(), they would still be able to do their their own per-character buffering, and their own numeric formatting and parsing, and thus be faster.

p.s. I call "Troll".

Broken C++ ABI ... again

[Lumpish Scholar]

They broke binary compatibility in gcc 3.0, and again in 3.2, and now in 3.4.

What do you think the outlook is for binary compatibility with 3.6?

Re:Broken C++ ABI ... again

[turgid]

I haven't seen that mentioned anywhere.

So go and read this very carefully:

The C++ ABI Section 3.3.3 specifications for the array construction routines __cxa_vec_new2 and __cxa_vec_new3 were changed to return NULL when the allocator argument returns NULL. These changes are incorporated into the libstdc++ runtime library.

GCJ with Java+QT

[bcore]

FWIW: I have done some app development on Linux using Java compiled with GCJ with UI provided by QT (through the KDEBindings package). I found it worked quite well, and the app was very responsive (didn't feel nearly as clunky as Swing apps often do).

My only complaint was that the occasional completely random feature seemed not to work, as though they had missed a few bindings.. I can't think of any examples, but it was nothing serious.

Re:pch

[0x0d0a]

For those not familiar with precompiled headers, you can basically look forward to *much* faster code compilation, especially with C++.

Precompiled headers are disabled by default in this release.

Re:GCJ

[rmathew]

Swing/AWT using Gtk+ peers has been making tremendous progress in the last few months thanks to a bunch of Red Hat hackers and is quite usable as can be seen here for example.

Unfortunately, these changes are not a part of the 3.4.0 release of GCC/GCJ and will only be available from 3.5.0 (or 4.0.0, as the case might be).

Re:GCJ

[XiC]

It works like a charm for me using swt on windows.

Have a look at http://www.thisiscool.com/gcc_mingw.htm for the windows version.

Also the java application still works as a java application using Linux and MacOSX (still using swt).

Re:Profiling shared libraries

[wowbagger]

My bad - there is a seperate program, sprof, that you use to profile the data from shared libraries.

Of course, gprof doesn't mention sprof in the manual, info pages, or in the error message, nor is it mentioned in any of the web pages about this subject.

Re:Idle curiosity

[arkanes]

From my experience:

MS "new" compiler compiles fast, optimizes well for both size and speed, and is very standards compliant.
BCC compiles very fast, optimizes well for size and speed, and is poorly standards compliant.
OpenWatcom is similiar to BCC
GCC (in the form of MingW) compiles slowly, optimizes well for speed but (very) poorly for size, and is very standards compliant.

Of the free beer options, on Windows, MS C++ 7.1 is the all-round winner imo. GCC/MingW is a very close second, however, with the main issues being much slower compile time (partially correctable via things like ccache, and the new pch support should help) and signifigantly larger binaries. In terms of standards compliance they're about equal, with GCC taking a slight lead.

New Features

[AT]

In addition to the usual bug fixes, there are some cool new features in gcc 3.4. Here is the full list; some of the more interesting stuff:

• unit (file) at a time compilation with -funit-at-a-time; now gcc can finally do some limited global (cross-function) optimization
  
• profile feedback (-fprofile-generate -fprofile-use options) that allows gcc to optimize based on feedback from runtime
  
• precompiled header files for huge compilation speed gains
  
• C++ now much closer to ISO standard
  

Thanks for #pragma once

[Anonymous Coward]

I'm very pleased to see that "#pragma once" has been rewritten and undeprecated in this new release of GCC.

That makes it easier for me to port Visual C++ code to GCC.

Thanks a lot.

Tom.

It should be noted that..

[XaXXon]

Precompiled headers were disabled FOR CAUSE in this version.

There are some known defects in the current precompiled header implementation that will result in compiler crashes in relatively rare situations. Therefore, precompiled headers should be considered a "technology preview" in this release.

Re:Fixed C++ ABI ... finally

[cimetmc]

A post above contradicts this, so I may be wrong about this...but I DO think I was remembering the binary incompatibility occurring in the 3.3 series correctly in this case. (My impression is that 3.4 doesn't have too many 'new features' beyond 3.3, but had more of a focus on optimizing the compile speed of 3.3.)

Well, you are wrong in a number of ways:

1) Like you already noticed yourself, GCC doesn't have the even/odd numbered version logic of Linux. Each version number is a release version. Development versions have the next release version with a date attached to the version. The development process is formalized and is described here

2) GCC 3.4 is a regular new version with a number of new features. It is certainly not a minor version with just some compile speed tuning. I would consider the changes from 3.3 to 3.4 bigger than the previous changes from 3.2 to 3.3.

3) The real oddball in the GCC 3.x series is GCC 3.2.x. This is just a bugfix version of GCC 3.1. However as some of the bugs fixed were a major C++ ABI issue and fixing those bugs lead to incompatibility, the GCC developers decicded to exceptionally increment the version number not following the regular release scheme.

Marcel