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!"
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
GCC 3.2 works great when compiling FreeBSD.
No, he isn't misreading it. The ABI has changed, this is nothing to do with compiling code.
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.
In the past few weeks I've been working on moving my main (home) server from Slackware on i386 to Debian on UltraSparc.
;)).
The Debian 3.0r0 install went fine (although for those trying it, be sure to select "rescue" when you boot off the CD). I recompiled my kernel using egcs64 and added RAID1 support into the kernel (with RAID0 as a module). I was able to setup my RAID partitions without difficulty, and the RAID0 arrays mount just fine. Unfortunately, when I try to mount the RAID1 arrays I get an oops, and any attempts to access the RAID device after that simply hang (that's a technical term
After a few searches on various mailing list archives, I found this post on the Linux-Sparc list. I tried this particular patch and was able to mount the RAID1, but after a few minutes copying data to the drive gave me another oops.
So, one supposition was that the oops was due to a compiler bug, but since egcs64 is so old (from 1998 I think) it's not going to get fixed. So I was looking at GCC 3.1.1 yesterday and got it installed but I was unable to compile a kernel with it (make couldn't find the compiler).
Is GCC 3.2 usable for Sparc? The GCC site had a report of a successful build of 2.4.18 using GCC 3.1.1 so I expect 3.2 would also work for UltraSparc. However, I tried to get GCC 3.1 working on a Gentoo install I did on my U30 and it died a horrible death. If GCC 3.2 will work, how do I install it as a replacement for GCC 2.95 and egcs64? When I installed the debs for 3.1.1 they didn't seem to replace either GCC or egcs. Can I pass some arguments to make-kpkg to provide the location of the compiler, as well as the -m64 option for UltraSparc?
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Did you compair the size of the code produced by 2.95.2 and 3.1? Yes, I noticed a speed-up (especially on my Alpha), but the compiled code was more than twice the size.
If you're using such software and it's dynamically linked, you could do the following: (as long as it's not SUID/SGID...)
/etc/ld.so.conf unless there aren't going to be newer versions of these libraries that recompiled programs will use...
1. ldd to determine what shared libraries are used -- at least, the ones that were specified at link time. Run-time linking, you'd need to determine by testing and perhaps strace().
2. Put copies of compatible versions of these libraries in a directory set up for this purpose.
3. Write a script that sets LD_LIBRARY_PATH to that directory, runs the program, and unsets it afterwards. Don't put this directory in
Then the binary should look in LD_LIBRARY_PATH first for the libraries.
If it's SUID/SGID... you'd probably need to do something more, like imprisoning the program in a chroot() jail with its own set of libraries, because ld.so will ignore the LD_LIBRARY_PATH variable in that case.
Only the dead have seen the end of war.
in fact, redhat already has gcc 3.2-1 in their rawhide distribution
The fact that you were using Gentoo 1.3 to me means you should have known it was dev the whole time. 1.3 is dev, 1.4 will be the stable version, and AFAIK 1.4 is going to be based on GCC 3.2. I could be wrong.
"More organs means more human." - Zim
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?
All compilers have to deal with an ABI.
"Calling convention" isn't an accurate enough term since it could describe a number of things in application development. ABI is better since it accurately implies it has something to do with the binaries themselves.
Essentially, the ABI is how a object files and libraries are linked together.
// file: mice.h
#include "frickin_lasers.h"
Intel's compiler defaults to the equivalent of -fno-strict-aliasing, regardless of optimization level. YOu have to pass -ansi to get it to optimize based on ansi aliasing rules.
Blame GDB. Maybe there will come a day when the GDB team understands that most people are not doing embedded work, and that C++ is *very* important.
That day is not here.
The reason you can't do things like useful debugging of optimized programs isn't because GCC can't produce the debug info necessary. It can, and would (IE patches exist that make it do so, and would be accepted without any trouble), but GDB can't handle the information.
This is unlikely to change unless someone whacks the GDB team upside the head. Most are embedded developers, and just don't get that the majority of GDB users don't care about cross-debugging 18 versions of the same chip, over a serial line. They want to be able to debug their desktop programs.
This is why things like namespace support, dwarf2 location expression/location list support, etc, are *not* priorities for gdb, but things like "multi-arch" (using one gdb to debug 18 OS/ISA/ABI variations of a given architecture) are *requirements* for targets not to be obsoleted.
This always seems to happen with a major release of GCC, it can't compile the latest release of glibc out of the box. This one dies with: ../sysdeps/unix/sysv/linux/errlist.c:41: weak declaration of `_old_sys_nerr' must precede definition
Too bad it isn't Friday, or else I'd just blow it off for the weekend. I'll probally look into fixing it now. (Don't worry I'll Google first).
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.
it's more than that...
C++ support operator overloading, so you can have
class foo::operator+(int);
class foo::operator+(const &foo);
class foo::method(int);
class foo::method(int, int);
class foo::method(enum xyx, const char *);
etc.
How can the linker tell which of the 3 functions was meant to be called? The compiler must (well, all of them work this way) mangle the name, so you actually are calling foo__method__int or foo__method__int_int (only it mangles it even more). As long as the compiler mangles the same way as the (static or dynamic) libraries it links against, they'll link fine. Incidently, the extern "C" prevents the name mangling (C doesn't support operator overloading).
The second issue is with the virtual lookup table. Basically, every class with virtual functions has a hidden array function pointers for the method (since the compiler/programmer doesn't know which method will ultimately be invoked. When a virtual function is called, instead of jumping to a subroutine directly, (foo__method__int(this, int)), it gets the function pointer from the virtual table within the class instance, and calls that function. The format of the virtual function table differs between compiler vendors, and between gcc versions in this case.
Do you even lift?
These aren't the 'roids you're looking for.
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.
API: Application-Programmer-Interface.
ABI: Application-Binary-Interface.
ABI is the convention used when creating object files (.o). How the assembly calling convention is, how the symbols are named... this sort of stuff.
42. Easy. What is 32 + 8 + 2?
Ryan T. Sammartino
"Ancora imparo"
This only affects C++ code. And only libraries and object files.
Also, it's perfectly possible to have both compilers on the same system. No need to rush for gcc-3.2, anyway.
42. Easy. What is 32 + 8 + 2?
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?
For those who want to compile GCC-3.2 yourself:
...
- you really should get/compile/install binutils--2.13.90.0.4 first!
- make sure you specify "--enable-shared --enable-threads=posix --enable-__cxa_atexit" when you do a 'configure' of GCC-3.2. Otherwise it won't be fully ABI compatible!!!
- then the usual "make bootstrap" etc
Good luck, Max
They did everything they could to fix all known C++ ABI bugs. I hope they really did fix all C++ ABI bugs, but there's a very small chance that there are still undiscovered bugs. Nobody knows wether there are still bugs left until somebody discover them (or not).
No, it means that GCC is now fully compatible with the "Common C++ ABI", a multi-vendor standard. This means that you can compile code C/C++ with GNU GCC and e.g. the Intel compiler and link both object files together. The resulting executable will work since both compilers have the same ABI!
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.
Yes, it's very nice that it was mentioned in the announcement for GCC 3.1.1.
Mandrake 9 Beta is based on 3.2 (as of Beta 2 - Beta 1 was based on 3.1.1). I also believe that Red Hat will be using 3.2 in their 8.0 release.
It makes it much harder to certify this though when the same behavior isn't present under gcc2.95x or other compilers, such as MSVC, MingW, or the *BSD compilers, etc.
Even if the aliasing case is indeed a bug in the code somewhere, the fact that -march=i686 works perfectly, while -march=athlon can cause X to segfault, the program segfault, or the program not show all the graphics leads me to believe it still needs help.
Don't get me wrong, I was happy to see the new Athlon option, but it doesn't do me much good when very minimalistic code gets generated incorrectly...
OS X mostly uses Objective C (like the various Step implementations) which doesn't have the C++ ABI problems: methods are implemented as messages of sorts. This approach means that you can have completely different objects which simply have some method in common, and call them the same way. Also, the Apple branch of gcc has many improvements over the main branch, namely the ability to mix Objective C and C++ (Objective C++). Everyone keeps naggin' the gcc maintainers to include those changes... perhaps now they'll have finally time to do it, so we can use programs like Chimera under GNUstep... I believe there are also many PPC optimizations in the apple version lacking in the main branch. So, it's really not that bad for apple...
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)
I've been using GCC 3.2_pre on a Gentoo Linux PIII laptop for about a month. Everything seems to work just fine.
That is, gcc 3.2 is the ONLY gcc on this computer. So the ABI interop issue isn't a problem, I suppose.
I can't find the link, but there was a good summary of a discussion (kernel cousin?) between users and distribution developers about the upcoming release plans for gcc. Apple had commiting to not upgrading to 3.2, but they would think about backporting bug fixes into their tree. Since they are the main distribution point for gcc for OSX, they'll be able to control it.
I suppose I'm not too threatening, presently, but wait till I start Nautilus
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)
And the third issue is how to represent exception-handling information, and the fourth issue is how to deal with typeinfo, and the fifth issue is initialization and destruction of namespace-scope objects, and the sixth issue is handling of covariant return types, and the seventh issue is merging static data in inline functions, and the eighth issue is representation of pointers to members, and...
A C++ ABI has to cover an awful lot of things. It's much, much more than just name mangling; that's one of the easy pieces.
gcc's C++ ABI is docuemented at http://www.codesourcery.com/cxx-abi/abi.html.
3.4 likely, Apple will be submitting their precompiled headers (PFE) after 3.3 comes out.
Repeated from comment 4079246: "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)."
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
But 2.95 is the one that didn't give the Linux kernel any problems. 2.95 allowed some long-obsolete constructs that are illegal under the ANSI standard. Allowing them impedes optimization, because it does not allow GCC to assume that what the guarantees is actually true. GCC3 decided to do away with this, and follow the standard as closely as possible. As a result, old buggy code (like the Linux kernel) no longer compiles. Some code will still compile under -O0 because even though GCC assumes things that the code doesn't, it doesn't actually take advantage of those assumptions to optimize things away. Only when it does do the bugs in the user code show up.
As an example, some code used to do things like write to a float* and then read it back as a long* (since on 32-bit systems, both are 32-bit values). This used to work, but under the current C and C++ standards is undefined. If the compiler does no optimization (-O0), you might get lucky and the code might still work, because you'll be physically reading and writing to the same memory address with same-sized pointers. But if you allow the compiler to optimize, it'll take advantage of the fact that when you write a float*, you can only legally read it back as a float*, and then your code breaks.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Newer versions of gcc have different sonames for the libstdc++ library. For example, gcc 3.1 used libstdc++.so.4. Backward binary compatibility is a non-issue. The only tricky issue is recompiling C++ libraries that you wish to use for your development with the new compiler.