GCC 3.0 Released

Phil Edwards, GCC Developer wrote in to say: "The first major release of the GNU Compiler Collection in nine years, GCC 3.0, is finished. There is a long list of new features, including a new x86 back-end, a new C++ library, and a new C++ ABI, to pick my three favorites. Note that the GCC project does not distribute binary packages, only source. And right now the server is heavily loaded, so if you intend to get the source tarball, please /. one of the many ftp mirror sites instead. Plans for 2.95.4 (bugfix release), 3.0.1 (bugfix release), and 3.1 (more user-visible features) are all in progress." MartinG points to this mailing list message announcing the upload.

Comments

Re:Why does GCC require so much memory?

[David Greene]

For one thing, the MS compiler & linker don't support automatic template instantiation. You may not have noticed this because the IDE does the bookeeping for you and generates the template declarations needed by the compiler.

This is not a bad thing. In fact, it is a very valid (I'd say good!) design decision. Explanation below.

For some reason, most compilers are faster when you turn of automatic instantiation and explicitly list the template instances you need.

The reason explicit instantiation is so much faster is that the compiler doesn't have to compile your code twice. Automatic template instantiation requires some sort of support outside the compiler proper. For all the gory details, I recommend Stan Lippman's Inside the C++ Object Model. It's a little out of date and inaccurate (or more properly, misleading) at times, but for anyone interested in why C++ works the way it does and what sort of decisions the compiler makes when generating code, it's a great book. It dispels many of the common myths about C++'s performance and makes an honest evaluation of the cases where performance is negatively affected.

But I digress. One of the most popular strategies for automatic template instantiation involves some sort of "collector" program. The basic idea is to collect all the object files that go into the final link and look for undefined symbols that refer to template code. The GNU collect2 program does this for g++. Once the symbols have been identified, the compiler needs some way of knowing how to recompile the source files that contain the template elements. Strategies include using control files generated by the compiler and collector, entries in the object files themselves (strings or symbols are common) or a combination of the two. Other strategies are possible as well. The driver script (the IDE in VC++) gathers this information and reinvokes the compiler to recompile the source files containing the needed template code, passing flags to tell the compiler to instantiate particular templates.

After having implemented some of this, I have to tell you that it is all a tremendous pain in the neck. It's also quite, quite convenient and necessary for the user. :)

As for the MS IDE, that's just another strategy for handling the problem. No compiler that I know of fully handles automatic template instantiation by itself. The closest that a compiler could come to this would be to aggregate the collector actions into the compiler as a separate phase. This is really no different that running a separate program and the "compiler" becomes the driver script (think g++), with the compiler proper (i.e. translation and transformation) being but one (usually, more than one) phase of compilation.

Every C++ compiler I've used on UNIX systems is painfully slow at optimizing template code.

Is this not true under Windows? I'm curious, as they should have many of the same problems. Optimizing template code is expensive because there is a lot of it and most of it is inlined. Inlining is not as trivial one might initially expect and it has large implications for transformation (optimization). Inlining usually greatly expands the size and scope of functions that are transformed. There are more nodes, more symbols and more analysis bookkeeping to handle. Many compiler algorithms have complexity of N^2 or worse (lots are NP-complete!) so things get dicey as code size expands. Strangely enough, this is also why transformation can speed up compilation -- it often removes nodes and symbols from the program!

--

But don't forget

[Ian Schmidt]

The very reason GCC 3.0 is out now rather than in 2005 is precisely because RH "jumped the gun" and submitted hundreds of bugfix patches to GCC 3.0 in the process. Meanwhile Redhat's GCC 2.96-81 is less buggy in my experience than 2.95.2 and the new features are great.

Here's the funny thing...

[bconway]

Guess what? Everyone that complained about GCC 2.96 being broken (and not reading http://www.bero.org/gcc296.html) despite the fact that their code wasn't C99 complient STILL WON'T COMPILE. Now you can't complain that your code won't work because it's a developmental compiler, you'll actually have to fix it. Numerous examples of this are listed at the above URL, I'd highly suggest you try it out. I have a feeling quite a few people are gonna be red in the face over this one. ;-)

Re:Question

[selectspec]

C99 standard. Overview.The Honorable Dennis Ritchie (father of C) on C99

The GCC developers should thank RedHat

[kdgarris]

The fact that RedHat used an earlier snapshot of this compiler allowed for extensive testing early in the development process, resulting in many bug-fixes being made to the snapshot as well as to the pre-3.0 GCC development code.

I'm sure this release came about sooner with a lot less bugs due to Redhat's move to use the earlier snapshot in their distro.

-Karl

Re:Question

[RevAaron]

What is Google?

Re:so

[langed]

Of course, they did the same thing that is done in the first stages of building gcc as a cross-compiler: build a compiler that compiles the compiler you'll eventually use. This early-stage compiler need not support all of C, only the parts that the compiler uses.
if you look in this Makefile, you'll see that in stages one and two it builds a program called xgcc, which it later deletes, but not before it compiles your cross-compiler.

the nice thing about doing this is that the compiler that is finally built when the entire compilation process is complete doesn't have to necessarily be "real C" in the source code. It could be a nice intermingling of any number of languages. It isn't, but it does give them that freedom.

So to review:
gcc (installed) -> xgcc -> new gcc compiler

Re:so

[TeknoHog]

The first GCC compiled itself. There is nothing contradictory here since, according to Novikov (see his book The River of Time) the present can be affected by future events.

This process is somewhat similar to the beginning of the universe, which according to Perl zealots started when tiny bits of eval() statements arose from quantum fluctuations. These immediately produced more and more eval()s, resulting in a big bang of code. Eventually, other functions appeared, forming the Universe as we know today.

There is also a controversial theory which asserts that the first GCC was written with assembler, and that the first assembler was written in binary code by Real Men (TM), but the evidence for this is questionable.

--

Re:Red Hat's problem...

[Erasmus Darwin]

Or if Red Hat users will now be forced to continue to use what has become obsolete software?

The existence of a new version of software does not (unless you're dealing with the ugly, ugly world of MS Office documents and their lack of backwards compatibility) automatically break older versions. You will not go bald, get cancer, or get attacked by a pack of rabid dogs just because you're using an older version of gcc. You will not see:

[erasmus@localhost ~]$ gcc -o test test.c -Wall
gcc: Version 3.0 has been released. You must upgrade. Sorry.

Furthermore, from the Slashdot blurb (right at the top of the page -- you don't even have to click a link), we've got the following:

Plans for 2.95.4 (bugfix release), 3.0.1 (bugfix release), and 3.1 (more user-visible features) are all in progress.

In short, the 2.9x line (which Redhat admittedly bastardized a bit by grabbing a snapshot and calling it 2.96) will still be fixed for bugs.

Also, for a production system, new, untested code is considered unacceptable. There are bugs in the 3.0 version of gcc, period. Over time, they will get fixed. But just like running an experimental kernel (or even the very first new stable release of a previously experimental kernel) is a great way to shoot yourself in the foot, you don't want to jump to gcc 3.0 unless you've got a reason to use it. And people who have a reason will generally be able to locate and install a copy of gcc 3.0, anyway. Hell, give it a few weeks and they should be able to locate and install an RPMed copy of gcc 3.0. And I'm sure there are people out there who will need gcc 3.0 -- it just won't be the core Redhat demographic, yet.

In short, did the people at work bitch at me for running RedHat 6.2 on our production machines at work? No. Would they have bitched if I had upgraded to 7.0 when it came out, broken things in the process, and used the excuse that they just need to wait a year for RedHat 7.2? Hell, yes. Even Slashdot does something similar -- there's plenty of lag between the latest version of Slashcode and what's running on Slashdot.

GJC! GJC!

[dasmegabyte]

GNU JAVA COMPILER!

I can finally write in Java and not get made fun of by my elite C++ hax0r friends!

In case you weren't aware, GCJ is the first Gnu toolset for Java, and it's not just a nasty rehash of Sun's stuff...it's JRE, JIT and NATIVE CODE COMPILER rolled into one. They have an odious refutation of the Write Once Run Anywhere creedo which I don't necessarily agree with (the guy must be writing some pretty fierce code if he's had problems like he mentions, I've done distributed Java with the Swing libraries for about a year and never had a problem that wasn't related to Netscape sucking). What I care about, though, is the speed ups. Finally, all my keen little utility programs I've written in clean, attractive Java code (to do stuff like rename files, play music and so on) will run as fast as OS level stuff. I intend on compiling the sweet ass netbeans ide as soon as they get AWT working. Maybe I'll finally be able to get it to run as fast on my shitty Celeron windows machine as it does on my MACOS lappy.

GNU TOOLS FOR LINUX: BECAUSE LINUX USERS HAVE A RIGHT TO CLEAN, ATTRACTIVE, EFFICIENT OBJECT ORIENTED CODE, TOO.