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.

pch

[rmull]

Yes! Precompiled headers will be miiiiiiiiine!!!!!

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.

new feature

[Tumbleweed]

"precompiled announcements"

but who

[mithras the prophet]

is still using a 386 anymore??? Get with the times, gcc! ;)

Ideally...

[me98411]

Ideally no one would have noticed until tomorrow, when the official announcement will go out..

They did not think about /., did they?

Profiling shared libraries

[wowbagger]

Has the ability to profile shared libraries been fixed? I have tried to do this, and even if you compile a shared library with -pg, and specify it in the LD_PROFILE environment variable, the resulting profile file cannot be processed by gprof V2.4 - instead you get "error: unsupported profile revision 131,071"

I *really* need to profile a shared library, and building it as a staticly linked executable is not an option.

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.

GCJ

[InsaneCreator]

Could someone explain how well does the gcj Java compiler work? I hear that AWT and Swing are not really usable, so how well does it work with SWT or maybe even wxWidgets?

I'm currently in the process of choosing the language/tools for a cross platform app (open source, of course) and I've narrowed the selection down to Java+gcj and c++. Native executables & widgets are a must, since my target audince most likely won't have a JVM installed.

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.

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).

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

[Dr.Dubious DDQ]

Well, if you want to be technical about it, it's not "Broken" C++ ABI, but a "Finally fixed, even though that makes it no longer bug-for-bug compatible with older GCC C++ ABI's"...

As I understand it, they've been working towards a more standards compliant C++ implementation, and that's why the binary compatibility gets lost.

I am, though, hoping that there was NOT a loss of compatibility between the 3.3.3 that I'm using now and the 3.4 series. Will find out once I clean off enough disk space to finish compiling up slack packages for myself...

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.

That's who

[fm6]

Well, these guys, these guys, and these guys seem to have no trouble selling 386-based hardware. Not everybody needs the full feature set (or the cost and power requirements) of a Pentium.

PCH and auto*

[greppling]

Has anybody done the work to setup PCH in a project built with the standard GNU Makefile tools autoconf/make/header? I tried it once, but didn't see a good solution to get the dependencies right. Of course, genuine support for it by automake would be great.

Re:WTF?

[jhunsake]

6) No screenshots

Idle curiosity

[bhima]

OK I know this is just idle curiosity but I think a general comparison between Microsoft's new offering, Borland's Free command line tools, Open Watcom and GCC might be interesting.

Re:Idle curiosity

[CoolGuySteve]

Don't forget ICC. If GCC could even begin to compete somewhat with the Intel compilers, the scientific community would probably take notice. From the experiences of the programmers and students at our department, Intel stuff is really buggy and wastes a lot of time with things like 'Internal Compiler Errors' and examples in the documentation that either don't work or don't compile.

Maybe IFC and ICC work better if you're not doing anything complicated or using exotic hardware, they probably weren't tested much on Itanium systems with 64GB of ram.

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
  

Re:Why are you only using even-numbered releases?

[chefren]

Gnome has been doing this as well and as far as I can tell they are fairly major. :)

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