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

Misplaced blame

[tepples]

Did you not get pleasure out of things being errors in 3.0 that weren't even warnings in 2.95?

At least the maintainers of the ISO C++ standard did.

GCC motto: "What code can we break today?

Blame the standards committee, not the GCC maintainers.

Re:Misplaced blame

[IntergalacticWalrus]

Your analogy is thoughtful but flawed. Unlike compilers, automobiles aren't built PRIOR to the solidification of their standards of manufacturing (yeah, thank God for that).

Re:Misplaced blame

[Alioth]

So basically the GCC developers are damned if they do, damned if they don't - if they fix their bugs to make their compiler ISO C++ compliant, they are whined at for following the standard, if they preserve the bugs, they are whined at for not following the standard!

Personally, I prefer GCC to be standards compliant.

Re:Moving fast

[Anonymous Coward]

There are a hell of a lot more users that depend on GCC then the paltry Apple userbase.

GCC is pretty much the standard for the industry.. there are faster, and more specialized, but GCC is the standard.

Linux/Unix/BSD/etc, IBM, servers, clients, embedded platforms, all hosts of different computers.

Hell if you just look at the embedded computers there are more of those then all the different desktop computers (Windows + *nix + Apple) put together.

Re:debian

[dhakbar]

I am curious why this AC's comment was modded troll. Is Debian's release cycle truly so slow that what appears to be an honest curiosity is modded as a troll?

vectorization very rarely works

[vlad_petric]

The main problem is the C language. While vectorizing a loop is generally not that difficult, figuring out if it's the right thing to do is extremely tough. To do that, you have to "prove" that iterations of a loop are independent of each other. This, in turn, requires good pointer alias analysis, and gcc isn't doing it well enough yet. BTW ... a language like Fortran, that doesn't have pointers at all, is much easier to vectorize; that's one of the reasons a lot of scientific codes are still in Fortran.

Without automatic vectorization, the performance benefit of compiling for 686 as opposed to 386 is simply minimal. A lot of people have done benchmarks on this, and found out that tuning for 686 with gcc only provides 1-2% improvements in the best case. Keep in mind that current X86 processors execute instructions out-of-order, so instruction scheduling for a specific pipeline is not going to do much (it's very important for in-order machines, though)

Re:"Paltry" is probably a poor choice of words

[1lus10n]

You have no concept of numbers. Both Linux and mac are minor on the desktop but close to 50% of the backend of the internet is handled by unix or unix like systems (not including apple). The vast majority of which use gcc or some derivative.

Unix and its children and cousins on the back and front end probably double the total number of apple boxes out there. If not more so. Hell some numbers suggest that there actually are more linux desktops than mac desktops. Even if its close between apple and linux on the desktop (which is likely) the number of nix systems in use in general at least matches the number on either side (though they are not desktops).

Re:Why?

[Sivar]

I know you were just poking fun but--

Standards are the reason that computers are tolerable to use for any purpose.
If a programmer can't be bothered to follow an international standard of his own language, there is no guarantee that the code is future-proof. One can hardly blame the compiler vendor, as we can't expect a compiler to mindlessly maintain backwards compatibility with every weird use of a bug and every bizarre code construct that has ever been supported in the past.

The ability to compile code written for GCC in another compiler is a *good* thing. If it requires informing the programmer that their code has always been broken, then so be it. A little inconvenience is a small price to pay for standards compliance, or should we expect that the GCC authors "embrace and extend" C and other languages until so much code relies on weird GCC nuggets that programmers (and users) are "locked in" to using just that compiler? (But Douglas Adams forbid if Microsoft does the same thing!)

Maybe I am missing something. If so, please enlighten me (This is not a sarcastic remark--I haven't done much research on what 4.0 has broken so I may be way out of line).

Sheesh, for as hard as the GCC authors work, and for as much GCC has improved in the last 10 years, the contributers sure get a lot of flak. Anyone who doesn't contribute code themselves should be greatful (or at least appreciative) of their efforts, even when they do make mistakes.

Re:Moving fast

[paulymer5]

Absolutely.

However, I was referring to the underutilization of Altivec in G4/G5 environments. Whereas SSA will be excellent across platforms, autovectorization will be especially significant on chipsets with powerful vector processors.

Being able to optimize for this hardware, which is not as common or powerful in the x86 world, without much effort is indeed significant.

I do not disagree with your assessment in the relative worth of SSA and vectorization, but I would simply like to clarify my post.