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.
hello world
0.01user 0.00system 0:00.00elapsed 142%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (52major+9minor)pagefaults 0swaps
3.0:
hello world
0.01user 0.00system 0:00.00elapsed 125%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (31major+11minor)pagefaults 0swaps
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!
--
- build just the C portion of GCC using the system compiler using no optimisations
- move the freshly built gcc aside (bins and object files) into
./stage1
- using the compiler in stage1, build all of the selected language portions of GCC, this time with optimisations.
- move this second compiler (bin and
.o) into ./stage2
- using the gcc in stage2, build a third copy of gcc, with the exact same optimisations.
- compare the third copy of gcc with that in stage2, if they differ, bail out
- build aditional libs (stdc++, iberty, etc)
- (if specified) install libs and the stage3 compiler
A slow, painful process (esp when doing porting work), but it ensures that GCC is at least good enough to build itself as the installed compiler is an exact copy of the compiler used to compile it.Bill - aka taniwha
--
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
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.
Yes. That is the point of the "gcc 2.96 Red Hat fiasco". The C++ library and ABI has been changed in 3.0 in order to conform to the C++ standard, as well as new cross-compiler C++ ABI standard, and to be much more efficient. The problem with the Red Hat release was that it was released half-way through that process, so it would be both forward and backward incompatible with the official FSF releases.
In most other ways, the unofficial gcc 2.96 is an improvement over 2.95, and for C code compatibility is as good as between any two releases of gcc. Mostly GCC 2.96 catches a few bugs that 2.95 failed to notice.
Programs that uses iostreams will tend to be slower, because of the new (ISO mandated) template based iostream implementation. In particular, a "hello world" program will tend to compile much slower, since it spend most of its time in the header.
Other programs can compile much faster or much slower, depending on what the bottleneck used to be, and what features they excersize.
There are several implementations of precompiled headers for GCC, which are likely to give a large boost in compilation speed when one of them is selected for inclusion.
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.
I remember try to build the TAO (the ACE ORB) a few years ago. Under Linux using GCC, a couple of files consumed all of virtual memory (requiring 250MB of memory). When I had sufficient, it would take my 128MB machine 45 to 70 mins to compile those particular files (lots of swapping). The same files under Windows with MSVC would take less than 20MB and thus compile in under a minute. What is GCC doing that requires so much memory? Is it me, or is this new inliner (that is such an improvement) still a memory hungry hog? Why? (Technical answers preferred).
--
Care about electronic freedom? Consider donating to the EFF!
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.
You've got it backwards. MS VC has it wrong too. the declaration of i in your example is scoped with the body of the for loop. 'i' does not exist after the closing brace of the for-loop.
This is per the ANSI/ISO C++ standard.
--jdp Maintainer of VisEmacs
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.
I've got some troubles with the newly compiled kernel. Sometimes, the kerboard blo
{{.sig}}
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
To my surprise, the Jikes version ran much faster, about 2X, than the native code. Only when I recompiled with GCJ with the option to skip array-bounds-checking, did the native version run at about the same speed as Jikes.
This post lists the non-compliance issues that VC7 will ship with. The for-loop scoping problem isn't there.
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?
The C Programming language was originally standardised in 1989, and this was known as C89 (and also as C90 - long story...) In 1999, the C language was updated with some new features and library functions. This is now known as C99.
#pragma is evil - anything after the #pragma is implementation defined. This means that #pragma blah on one compiler might do one thing and something else entirely on another. You can't conditionally use it per compiler since it's at the pre-processor level. (You can't #ifdef out #endif, for example.) _Pragma is nicer, however, as you can do: #if <test for GCC> #define BLAH _Pragma whatever #elif <test for other compiler supporting such enlightenment> #define BLAH whatever #endif BLAH Unfortunately I don't know of any other compilers that realise this, so you're sort of stuffed. Most of them allow #pragmas to be ifdef'd out which is nearly as good.
a) printf statements and I/O inside loops in a performance benchmark? hello, McFly... you aren't really testing the compiler there.
b) gcc only as source??? (see your installation media for any free unix to get binaries, cygwin for win32, etc. etc. GNU may only distribute source but other folks can and do distribute binaries, and I'm sure gcc 3.0 binaries will be released for your platform of choice Real Soon Now)
c) FP perf: what do those numbers mean? There is no explanation given of how they're arrived at or what scale they're on. "Naked numbers unlike naked ladies aren't terribly interesting."
d) Ease of Use/Installation: Totally subjective and totally irrelevant to the merits of the compiler. Just because a preteen could install VC++ doesn't make it's code any better.
e) "overhyped","not ready" gcc: ok, so you're a troll. Just try not to be flaming stupid while you're at it. If it isn't ready then why is the operating system I'm using to type this reply on built with it? Is gcc the best compiler ever, well, no, there's no such thing. Frankly I wish gcc supported something more recent in the fortran family than F77 (not that I like Fortran per se but as a scientific coder it's sort of common and stuff).
--
News for geeks in Austin: www.geekaustin.org
News for Geeks in Austin, TX
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"?
Did they manage to speed up g++ at all? In the prerelease versions, I was seeing compilation times that would put g++ 3.0 at about 2-3 times slower than 2.95.2. And 2.95.2 was significantly slower than any egcs version. Anyone know if there are plans to address this?
Actually what is happening is that as the tools we create and use become more and more sophisticated (and thus more lines of code in use), the harder it becomes to catch all the possible things that could go wrong in an application. With big projects like the Linux Kernel, GCC, Mozilla (now in beta), KDE, Gnome, XFree86- it is just realistic to assume that even though the developers worked very hard for a stable release, people will find bugs.
I miss the Karma Whores.
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