Slashdot Mirror
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.
This is not a bad thing. In fact, it is a very valid (I'd say good!) design decision. Explanation below.
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.
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!
--
AFAIK, gcc requires a *K&R* C compiler, as documented in the first edition of The C Programming Language. It need not support function prototypes or the void type (I think).
On UNIX systems that do not natively support and include gcc, one uses the system's C compiler to generate xgcc, which is GNU C (but not compiled by GNU C). One then uses xgcc to generate a GNU-compiled gcc. I don't know why xgcc is not normally installed and used, but I assume that it would be an ease-of-debugging issue (and you can also debug gcc-optimized code, which most vendor compilers will not do).
HP-UX natively includes a K&R (non-ANSI) C compiler. It is almost useless, but it will successfully compile gcc. On most other commercial UNIX systems, if you lack a compiler, you must rely upon someone who has a compiler to generate a verstion of gcc for you (which accounts for the popularity of packaged gcc versions on many platforms). This can also be complicated by licensing of the system include files and libraries.
GCC is basically a new name for EGCS.
I don't know about PGCC, but since GCC 3.0 has a brand new ia32 backend with focus on Pentium II performance, chances are that PGCC is no longer relevant.
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.
I'd say they're just being realistic. No matter how good your QA process, the chances of catching and squashing every single bug before release are minimal. The best you can realistically hope to do is catch all the real show stoppers. (Assuming that you actually do want to release the product at some point, that is)
:)
Having said that, this is the first time (that I can remember) that I've seen an officially-planned x.0.1 bugfix release announced at the same time
Cheers,
Tim
It's official. Most of you are morons.
Not much, hopefully.
The only major thing that can affect the binary packages is the new C++ ABI. But for plain C programs, there should be no big difference. Most of the Linux programs and libraries are written in C and should not be affected significantly. This could be a problem for Qt and KDE packages, though.
See also the list of caveats on the GCC web site.
-Raphaël
We did consider the name GJC (back in '96 when the project was started), but for some reason I don't remember (I think it was trademark-related) we decided on GCJ.
I'm very glad to see GCJ in a mainstream GCC release, and hope it will finally get the attention I think it deserves.
Of course, they will do what they've always done (and every other commercial vendor with large customers does). They will distribute "obsolete" software until their next version, when they will go with the almost-latest-and-greatest that they can get to work.
You have to understand, Red Hat bowed to their customers. Many of their C++ customers told them they needed ANSI C++ compliance badly. GCC 2.96 offered that.
Red Hat has a history of working hard on the compiler, and distributing a custom version. They were the first distribution to ship egcs (remember, 6.2 ran egcs for the C++ compiler). They also did a lot of work on making egcs work for the Linux kernel.
--
Aaron Sherman (ajs@ajs.com)
For those of you who prefer a non-hacker announcement of the release, a press release is available.
So how did they compile the first version of the GCC compiler? Seeing is that there was no prior GCC compiler first?
Or if Red Hat users will now be forced to continue to use what has become obsolete software?
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. ;-)
Interested in open source engine management for your Subaru?
AFAIK, gcc requires a *K&R* C compiler, as documented in the first edition of The C Programming Language. It need not support function prototypes or the void type (I think).
No, it does not require such a compiler; it is required to be bootstrappable with such a compiler.
And K&R did have void. They didn't have pointer to void.
On UNIX systems that do not natively support and include gcc, one uses the system's C compiler to generate xgcc, which is GNU C (but not compiled by GNU C).
Not really. xgcc is the name of the result of the stage1 and stage2 bootstraps; the stage2 one is created by the stage1 one (i.e. by GCC).
I don't know why xgcc is not normally installed and used
It effectively is, if you type "make install". The bootstrap process just ensures that the result of the stage3 bootstrap has identical object files as the result of the stage2 bootstrap, which formed xgcc. In other words,
that optimized GCC compiles itself into the same optimized GCC - a consistency check. Those binaries are what get installed, so it is effectively the same GCC.
but I assume that it would be an ease-of-debugging issue (and you can also debug gcc-optimized code, which most vendor compilers will not do).
Nothing to do with it. Everything after stage1 is a consistency check.
C99 standard. Overview.The Honorable Dennis Ritchie (father of C) on C99
Someone you trust is one of us.
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
ABI == Application Binary Interface.
:(
:)
It's the format for putting things like function names in object files so that the linker, when fixing up function calls across object files, can match the call with the correct function.
While this isn't a problem in C (just use the function's name for christ's sake), C++ allows overloaded functions; multiple functions with the same name but different parameter lists. For the linker to match the correct call to the correct function, the parameter list needs to be munged into the function name stored in an object file.
The new way of doing it is generally less clunky and takes up less space in your object files than the old way. But is incompatible with it.
(Note that this only matters where GCC is being used as a native compiler to compile files that only need to be linked with each other. If compiling for a platform where gcc is not the native compiler (e.g. using GCC on, say, solaris, alongside the default compiler) you need to use the ABI defined for that platform to allow your object files to be linked with all the other object files you have that were compiled with the native compiler.)
Yeah, it's more than 100 words. Sue me
Why doesn't the gene pool have a life guard?
What is Google?
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
No matter how good your QA process, the chances of catching and squashing every single bug before release are minimal
Unless you're Microsoft; then you're an incompetent, obnoxious, FUD-spouting dinosaur and every bug that escapes is an indictment of you, your business practices, design methodology, family heritage, preference for breakfast cereal, haircut and anything else associtated with you or anyone you have ever met, slept with, laid eyes upon, or casually passed on the street.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
I use a lot of JAVA, and it looks like we will finally have a full JAVA front-end for gcc with dependency generation (for automatic makefiles).
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.
Hey freaks: now you're ju