Slashdot Mirror
GCC 3.2 Released
bkor forwards the GCC 3.2 release announcement, without attributing it as such: "The GCC 3.2 release is now available, or making its way to,
the GNU FTP sites. The purpose of this release is to provide a stable platform for OS distributors to use building their next OS releases. A
primary objective was to stabilize the C++ ABI; we believe that the interface to the compiler and the C++ standard library are now stable. There are almost no other bug-fixes or improvements in this
compiler, relative to GCC 3.1.1. Be aware that C++ code compiled by GCC 3.2 will not interoperate with code compiled by GCC 3.1.1. More detail about the release is available. Many people contributed to this release -- too many to name here!"
This is front-page material because GCC is one of the most important building blocks of the free/open-source software world.
GCC is the de facto compiler for GNU/Linux and *BSD systems. Furthermore, the Linux kernel currently hasn't been ported off GCC. Without GCC, free *NIX systems would have nowhere near the importance they have now.
#define sig "Every social system runs on the people's belief in it."
I've been waiting for this. Building glibc in the past w/ gcc3 was PAINFUL beyond measure. There are still many optimization options that I have to use with programs otherwise gcc3's optimizers optimize away too much.
:)
For example, if I compile the modified Quake engine project I work on without -fno-strict-aliasing bizarre graphical errors occur. (Or used, need to check 3.2 now
Or if I compile with -march=athlon I get fairly mixed results, code that sometimes segfaults for no apparent reason, etc.
Anyway, congrats to the gcc3.2 team...
They do and they have promised to keep the C and C++ ABI stable for the future. (They promised the same thing for 3.1 but some bugs in the 3.1 code forced them to change the ABI again).
Martin Tilsted
aware that C++ code compiled by GCC 3.2 will not interoperate with code compiled by GCC 3.1.1
Good thing I didn't waste an entire f*cking week compiling Gentoo 1.3 with GCC 3.1. It would have been a STUPID WASTE of time if I had done that. Yeah, good thing I saw this coming.
GOD DAMNED PIECE OF F*CKING SH*T!
Don't blindly follow the "GCC produces slow code"-trend just because of that comparison between GCC en Intel C++ a few months ago on Slashdot.
Since release 3.1, GCC produces *fast* code. On my Pentium 233 MMX, bzip2 is 25% faster when compiled with GCC 3.1 than the binary produced by GCC 2.95.2. The optimizers have been greatly improved, and can compete with Intel C++. On some areas, GCC is faster, while on other areas, GCC is slower than Intel C++. But all in all, GCC is quite good.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Looks like it produces smaller code than 3.1:
.config files.
803130 Aug 15 13:18 vmlinuz
804713 Aug 6 09:08 vmlinuz.old
At least by a tiny bit. Those are both Linux 2.4.19 kernels with the same
If -fno-strict-aliasing fixes the glitches, it could be an invalid assumption in the C code.
,the compiler tries to figure out if 2 pointers point to different addresses. If it's guaranteed that they point to different addresses, then the compiler will reorder read and write operations.
Read the gcc docu for the details: With the alias analysis
The new C standard contains very strict rules about pointers, e.g. writing into an array with a "double *" pointer, and reading back with a "long *" pointer is now undefined.
Have you tried Intel's compiler, set to maximum optimization?
Please remember that the C++ standards comitee encouraged vendors to use different (incompatible) ABIs for C++. C++ compilers were not supposed to interoperate, because they thought that this would never work, because the compiler had to do far too much things outside the object files (compilation units) for exception handling and initialization code.
And, for all compilers I know, they were right.
You really cannot blame the GCC people for this. Whenever they have to change the internal handling of exceptions, templates and stuff internally, it really is the best choice to change the ABI.
The C++ standard was never designed to make code compiled by different compilers link. And gcc2, gcc3.1, and gcc3.2 are different compilers because the internal handling of these very complex structures changed.
42. Easy. What is 32 + 8 + 2?
Application Binary Interface
ABI's define what is necessary for two pieces of compiled code to interoperate properly. So you have OS ABI's (which define syscall interfaces, argument passing, etc), Programming language ABI's (C++'s ABI generally includes virtual table format, name mangling format, exception handling format, etc), etc.
Think of it as the API defined for compiled code.
Compiled code that is compliant with a given ABI will interoperate properly with other code compliant to that ABI.
You know that GCC has been tested more with optimization turned on than with -O0 (no optimization)?
About two years ago, I was compiling linuxconf. The Makefiles forced -O0 (no optimization), and its author, asked, said that "there will be errors by the compiler when I turn on optimization, so I force it to be off for everyone."
It turned out there was a bug in his code. It wasn't gcc's fault. It just showed up when you used optimization. But, btw, the code of Linuxconf has been ugly as hell since I first saw it.
Code that won't compile (or break) at -O1 is crap.
42. Easy. What is 32 + 8 + 2?
Does anybody know when GCC wil finally support precompiled headers?
This is really bad timing for Apple folks.
AFAIK, the entirety of Jaguar is compiled with GCC 3.1. Replacing all the libraries with v3.2 is gonna be some mighty huge software updates...
Bugs that come and go depending upon whether strict aliasing rules are assumed or not are generally due to broken code. The C standard is quite explicit about when aliasing is allowed and when it isn't. (Aliasing is when there are two or more pointers to the same region of memory. This is generally OK if the pointers are of the same type, or if an appropriate union is used. Two pointers of different types pointing to the same region of memory are generally veboten (char* is an exception).)
The aliasing rules tend to be a source of trouble since violating them was fairly common in pre-standard days. (The V6 Unix kernel used to use generic pointers -- like "register *p" -- just about everywhere, something that is prohibited under ANSI.) They exist to allow the compiler to optimize based on the assumption that only pointers of the appropriate type can be used to access a stored value, and thus that value can be assumed to be unmodified (allowing redundant accesses to be eliminated) in a larger number of cases.
A Google search on "C aliasing" will turn up a fair amount of info on the subject.
Finally a stable C++ ABI ???
1. This means that C++ _including objects+classes+ will, with a bit of grunt work, be able to be integrated with real-oo scripting languages just as easily as C - it's the constantly changing C++ ABI that has prevented, until now, "easy" bridging of, say, C++'s object model to Common Lisp's CLOS, without having to recompile everything in sight at the drop of a hat - it will now be possible to produce a C++-to-lisp analogue of, say, CMUCL's excellent "alien:" lisp package (nothing to do with the deb2rpm tool), or SWIG-but-for-proper+C++ for python and perl.
2. It will mean that third-party binary distribution of C++ code is a lot more viable. Remember the way Netscape, Realplayer and flash used to break with every new RedHat release? - well, that was primarily becuase of libstdc++ not linking properly due to changing ABI.
3. This should also mean that the prelink "hack" and it's ld.so-integrated successor can stabilise and become part of standard linux distros - no mare agonisingly slow KDE startup times!
If you compile programs or libraries with GCC 3.2, they won't be able to link against libraries that were compiled with prior GCC compiler versions. But this only affects C++ code! C code is unaffected.
And: This isn't really a problem if you compile on your own anyway. You just don't need to "switch compilers". Just do a parallel installation. For example: ../gcc-3.2/configure --program-suffix=32 --prefix=/usr && make bootstrap and it will end up
as "gcc32" in your system.
42. Easy. What is 32 + 8 + 2?
I got into a good habit at my first SysAdminning job that prevents this kinda problem. Make a directory in /usr/local/package/. Make a subdirectory dist, and untar the source there. configure --prefix=/usr/local/package/. make and make install, and then when you have all your /usr/local/package/bin/ and lib directories, make sym links.
/usr/local/* | grep '-> /usr/local/package/'`; do rm $F; done".
/usr/local/package/version/architecture/, but I consider that overkill on my home machine.
"Uninstalling" and "upgrading" becomes as easy as "for F in `ls -l
At the aforementioned job, the directory I installed to was actually
Hi. I'm one of the hundred-odd GCC maintainers.
Because the idea of backwards compatability never occured to any of us until we read your Insightful post. My God, what a concept! I'll go tell them at once!
Seriously, what makes you think the entire team doesn't already understand this point? Do you think such decisions are made lightly? Go read the archives; they agonized over this for months, and that was before the heavy debating started.
Here's the simple fact: there is a C++ ABI designed for compatability and interoperability. Here's another simple fact: there were bugs in our implementation of the ABI. The choice was to be backwards-compatable with previous GCC 3.1 and incompatable with other vendors implementing the same spec -- which would pretty much defeat the purpose of a common ABI. Or we could fix the bugs and break compatability in a couple of corner cases.
Of course, after all the details are worked out is when all of the geniuses with answers to all of life's problems decide to reveal The One True Solution on /. posts...
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
The C++ standard says nothing about ABIs. (Well, there are some layout rules when dealing with POD structs, but nothing about a C++ ABI.)
We're not meeting the C++ standard in two regards (at least I can't think of any more): first, we don't have export for templates. That will largely be a fallout of the precompiled header projects (two or three PCH branches have been in the repository for a long time now; both Apple and Red Hat have been contributing their implementations).
Second, we don't do two-stage name lookup for templates. Which most user don't need to worry about. That will come when the current 15-year-old parser has finished being rewritten (and there are branches doing that already as well).
Also, keep in mind that although the compiler C++ ABI is stable, the C++ library ABI is not. Declaring it stable at this point would be a massively stupid thing to do; there are far too many optimizations to be made still, and those involve changing the ABI. For example, there's a reworking of the memory allocator that currently exists on my whiteboard, and as soon as it gets finished off and checked in, the library ABI will be broken. Vendors already have methods in place for dealing with multiple versions of a library installed; this will be nothing new to them.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)