GCC 4.0.0 Released

busfahrer writes "Version 4.0.0 of the GNU Compiler Collection has been released. You can read the changelog or you can download the source tarball. The new version finally features SSA for trees, allowing for a completely new optimization framework." The changelog is pretty lengthy, and there's updates for every language supported from Ada to Java in addition to the usual flavors of C.

Comments

Moving fast

[slapout]

Is it just me or did the jump from version 3 to 4 happen a lot faster than the one from 2 to 3?

Re:Moving fast

[JohnsonWax]

Apple wasn't working on GCC until version 3. I suspect a lot of other companies weren't either.

Re:Moving fast

[burns210]

Apple is using it in their Tiger (OS X 10.4) release come the 29th of this month. So there is a few millions new GCC 4.0 users right there.

i'm having horrible flashbacks...

[ribo-bailey]

of the 2.95 -> 3.0 transition.

Is anyone else curious what SSA trees are?

[Da w00t]

Not a C coder myself, (sticking mainly to perl).. I've just got to ask, what are SSA trees, and what benefit do they serve?

Re:Is anyone else curious what SSA trees are?

[rbarreira]

An educated guess - are they a move in the direction of making code optimizations in gcc easier to code? I heard that a lot of optimization experts (you need to know a lot of graph theory for example) wouldn't work on gcc because of the difficulty of working with it for optimizations, so they would do their experiments in other compilers...

whoa

[william_w_bush]

reading tfa and changelog intrigued me. optimisations aside im curious if this will be better able to thread on the new multi-core systems coming out, as tls has been spotty till 3.3 and glibc 2. maybe native xd support coming soon too?

also, the c++ side makes me feel optimistic about ongoing support, which had been a big problem till 3.4.

yes im x86/64 centric.

Re:whoa

[AHumbleOpinion]

... I assume these extensions you speak of don't involve automatically adding threads to a program ...

Actually they do just that. You put a #pragma omp before a for loop to have it implemented using threads. You put another #pragma omp before access to a shared variable to have access serialized. You never code to a specific API. The compiler automatically generates pthread calls, Win32 calls, etc as appropriate. Your code is portable. Lawrence Livermore has some nice examples but the seem to be down right now, www.llnl.gov.

Autovectorization

[QuantumG]

Correct me if I'm wrong here, but most Linux distributions are still i386 right? It's only the people who use Gentoo who actually compile everything with i686 options right? So, if autovectorization and all the other improvements in GCC 4.0 make binaries massively faster on modern platforms, how long will it be before the major binary based distributions (like Ubuntu) start making i686 the default and i386 an available alternative (like AMD64 is now).

Re:Autovectorization

[QuantumG]

I used to work for Codeplay, a company that made compilers for games development, and we were pretty surprised at the kinds of speedups you would get on non-gaming applications. Obviously compiling open source software was a great way to test our compiler. Basically any loop which performs the same operation on multiple data can be unrolled 4 times and vectorized. That's a massive speedup. So yes, I would expect OpenOffice to be faster.

Re:Autovectorization

[mattdm]

Correct me if I'm wrong here, but most Linux distributions are still i386 right?

Right in some ways, but importantly wrong in others. Red Hat and the Fedora Project, for example, are compiled using the i386 instruction set but optimized for i686. This means that the cmov instruction isn't available -- but apparently, it's not much of a win (and even a loss in some cases) on modern processors. And code which uses SSE or 3DNow or whathaveyou is usually carefully hand-coded and checked for at runtime.

There's not really much advantage of switching away from this scheme, so I don't see it as worth the bother. Instead, x86_64 will eventually kill it all off and we'll move on to that.

Figured this had to happen

[jtshaw]

When they announced the release of Apple 10.4 "Tiger" I noticed this page: At that point I kinda figured gcc 4.0.0 had to be out by April 29th since Apple claimed they were using it for OS X.

Re:Figured this had to happen

[As Seen On TV]

If anybody was wondering, this is why we stay as far away from the Gnu people as humanly possible.

We're not shipping "a fork" of GCC 4. We're shipping GCC 4.0.0, which we compiled from source for Darwin 8.

In fact, when you're talking about shipping a compiler for a specific platform, the whole notion of "a fork" is basically meaningless.

(Setting aside, of course, that the whole notion of "a fork" runs 100% counter to all that open-source stuff that you guys are supposedly so hip to anyway.)

Re:Figured this had to happen

[As Seen On TV]

You're defining "fork" so broadly that every build from every vendor would meet it. That's pretty silly.

Compatibility? Linux testing?

[H0p313ss]

Just about every time I have to rebuild a kernel or build a kernel mod I get my butt kicked by gcc versions. So my questions are?

• Are there compatibility issues with existing binaries?
• What does this do to existing code?
• How will this effect existing distros?
• Is any distro planning on supporting 4.X soon? (And is that a good thing or a bad thing?)

Anyone know?

Readme.SCO

[karvind]

The gcc tar ball has a README.SCO file (reproduced below)

The GCC team has been urged to drop support for SCO Unix from GCC, as a protest against SCO's irresponsible aggression against free software and GNU/Linux. We have decided to take no action at this time, as we no longer believe that SCO is a serious threat.

For more on the FSF's position regarding SCO's attacks on free software, please read:

http://www.gnu.org/philosophy/sco/sco.html

Re:Readme.SCO

[NutscrapeSucks]

Maybe someone can find it, but the SCO GCC guy posted on Slashdot once. He indicated that he was pretty much single-handedly responsible for the SCO UNIX port, so GCC pulling their endorcement wouldn't make much if any difference to SCO customers. I belive his attitude towards his employer was "I don't like it but who else will pay me to hack on GCC?"

how much java comaptibility

[b17bmbr]

i am interested in the java compatibility. i figure it probably won't do swing, but will it support, or is will it do say gtk/java native. that'd be sweet. i know Qt/kde has had a java bridge for a while, but i really haven't played to much with it. flame java all you want, it's not a geek language. no obfuscated java, no java monks. BFD. sure that'd nix the whole write-once run anywhdere thing. but hell, what a great opportunity to build and test apps under a jre then compile them, to native.

Objective-C++...?

[Dimwit]

They've been talking about having Objective-C++ in the GCC main branch for years now. There was even talk that 4.0 wouldn't ship without it. Now it's shipped without it and it's still "coming Real Soon Now". Any word on if it's coming any time soon (really)?

Re:Objective-C++...?

[framerate]

"All the ISVs who are still using C++ are building their apps with Core Foundation."

No they're not! And I myself am not about to port hundreds of thousands of lines of C++ code to Objective-C since that'd eliminate the Windows version, which I can't do!

In the code base I'm currently porting to Cocoa, all of the application's core logic and data structures are written in C++, and the user-interface layer is written natively for each platform. So the Mac version gets a high-quality Cocoa front-end and Windows/Linux/BSD gets a wxWidgets front-end (since wxWidgets does a good job on those platforms).

Take away Objective-C++ (and therefore Cocoa C++) support and I'll just compile the wxWidgets version for the Mac since CoreFoundation is, as you say, a pain in the ass to use. The result: another low-quality "Windows-app-in-Aqua-clothing" Mac app.

Cross-platform toolkits, such as wxWidgets, SWT and Swing produce usable but low-quality Mac applications (missing sheets, drawers, collapsable toolbars, AppleScript support, and so on and so forth). Objective-C++ allows me to easily write high quality Aqua-compliant applications easily. So if Apple values Mac users it will keep supporting Objective-C++!

Not to mention that, for me at least, Cocoa/C++ is one of the reasons I use a Mac in the first place. I can produce professional user interfaces in no time and still know that I can port the core logic to Windows/Linux/BSD.

Oh, and I'm working in the games industry, where the majority of code is C++. I know for a fact that Apple wants more games code ported to OS X.

Re:debian

[Anonymous Coward]

Is Debian's release cycle truly so slow that what appears to be an honest curiosity is modded as a troll?

Kidding aside, no. Debian is legendary for being, ahem, slow about releases; they release when it's done, not on some date. Thus /. gets lots of jokes about Debian being slow. "I heard that Duke Nukem Forever will be open source and part of Debian's next release!!!11!" etc.

If GCC 4.0 made changes that would affect the ability of the linker to link things, then GCC 4.0 would actually be slow to go into Debian. Packages would probably show up right away in Debian Experimental but otherwise would stay out for a long time.

Debian Unstable ("sid") is where the new, potentially unstable, stuff goes once it is out of Experimental. Things in Unstable are automatically promoted into Testing if they look stable, which means the Debian guys can't put anything half-baked into Unstable. They would have to wait until the current Testing is released as Stable, and then they could do a big change like that. The current Testing ("sarge") is getting closer to actually shipping but I don't know when exactly.

As long as GCC 4.0 simply produces better code, and doesn't break anything, it will show up in Unstable within a very short amount of time. I don't know enough about it to tell you whether this will happen or not, but I did read the release notes and I don't see anything in there that looks like linker breakage.

Shouldn't they have done this 10 years ago?

[Old Wolf]

One of the changes in 4.0.0 is autovectorization optimizing.
One _ancient_ compiler (10+ years) I have to use, already has this feature -- and on a large scale: it'll do it over several screensful of code. What took GCC so long?

Unfortunately, this compiler I mention also has a bug: once it's factored out 'i' in a piece of code like that below, it then complains that 'i' is an unused variable. So you have to do something with 'i' to suppress that warning, which kinda defeats the purpose of the autovectorization.

Sample code:

int a[256], b[256], c[256];
foo () {
int i;

for (i=0; i256; i++){
a[i] = b[i] + c[i];
}
}

Example

[TeknoHog]

For an example of a sensible (slightly higher-level) language, consider the Fortran example from the autovectorization page:

DIMENSION A(1000000), B(1000000), C(1000000)
READ*, X, Y
A = LOG(X); B = LOG(Y); C = A + B
PRINT*, C(500000)
END

Notice the lack of an array index. These are true vector operations to begin with, so it is already assumed that the array elements are independent, therefore the log and addition can be parallelized safely.