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!"
That's great, but i'm still waiting for a flow-matic front-end
Jonahweb.com has stuff.
yeah, lol, just like watching a "I Love Lucy" rerun on an old Black & White Television...
Come on..I know people dying to rush out and try to compile a kernel with this thing...I mean that's what it was released for "building OSes.."
If I wasn't at work I'd try it...sigh.
But my guess is that it doesn't.
Be aware that C++ code compiled by GCC 3.2 will not interoperate with code compiled by GCC 3.1.1.
When will they understand that breaking interoperability is not the way to go forward? The reason MS Windows is where it is now is that you don't have to replace/recompile all your software every few months.
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."
"The GCC 3.2 release is now available, blah blah blah. The purpose of this release is to provide a stable blah blah blah releases. blah blah blah stabilize the C++ ABI; we believe blah blah blah are now stable. blah blah blah. Be awareblah blah blah GCC 3.2 will not interoperate blah blah blah GCC 3.1.1. blah blah blah"
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
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...
So soon I'll be able to emerge world --update to Gentoo 1.4? Yay!
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
That means that RedHat can now release Red Hat Linux 8.0, complete with GCC 3.2
Um, perhaps you are misreading that.
Essentially, code designed to compile with 3.2 won't compile with 3.1.1; code that compiles with 3.1.1 will probably compile properly with 3.2.
GCC 3.2 works great when compiling FreeBSD.
And how much stuff was actually compiled with GCC 3.11? They probably didn't want you using 3.11 for your critical apps anyways if they had all these bugs to fix =)
But its nice they finally settled on a stable ABI, so all releases forward of this one will be compatible.
Err...:
:)"
:D
"(Or used, need to check 3.2 now
should be:
"(Or used to, need to check 3.2 now:)"
Sigh. The gremlins enjoy mangling my mind
(They promised the same thing for 3.1 but some bugs in the 3.1 code forced them to change the ABI again).
Lessee here. This release is the last time we are going to break compatibility. (repeat whenever needed)
Sounds about like every piece of commercial software that I have ever worked on.
Does anyone knows any good compiler that works on many platforms and generates good and highly code on intel?
I'm sick and tired of GCC, it's a shitty compiler.
No, he isn't misreading it. The ABI has changed, this is nothing to do with compiling code.
Yes, I know about Gentoo. I'm looking into it.
There is also the problem that a lot of C++ code does not compile with 3.x...
I have been waiting for this release for quite a while now. The entire gcc 2.x vs 3.x incompatability thing has been driving me nuts.
What am I supposed to do with games/commercial software compiled with 2.95.x? Is that not going to work? Someone please enlighten me...
A good comment passed to me was "why can't you just install an app for 'kernel version x' instead of it being for 'kernel x but with glib y' or any of the other endless possible configurations?"
What I'd really like to see is gdb working with GCC3.2. We've been developing with gnu c++ 3.1 here, and 3.1 is much more standards-compliant than, say, 2.96. However, using gdb in conjunction with it is a real headache. Perhaps with this stabilized 3.2 release, there shall come a day when gdb is really useful.
Well, I compiled all the software on my Gentoo system with GCC 3.1, presuming the ABI would be stable. It worked perfectly fine (no crashes, ever). Well, its a couple of days of recompiling for me, I guess.
A deep unwavering belief is a sure sign you're missing something...
This is a huge step forward, once gcc 3.2 becomes widely distributed it will finally be practical to have binary releases of c++ software with the expectation that it will actually work!
previously, this was basically impossible because the C++ ABI was not stable so you could never expect object files compiled with different versions of g++ to be link-compatible. And, it took until gcc 3 before the C++ standard library was useable. Prior to this, it was common to use something like STLport, but then it becomes problematic to distribute even as source, because of the dependency on STLport.
With gcc 3, it finally became possible to reliably distribute free-standing c++ programs as source. With gcc 3.2, it becomes possible to distribute binaries! cool!
Yes it is - as a coder, finally having stable C++ compiling is a big, big deal.
While I understand your point, it seems almost out of place here.
The ABI was changed for (hopefully) good reasons. These reasons probably included speed, ease of compilation/optimization, stability, etc. Further, it is safe to presume that these changes could not have been addressed successfully without changing the ABI. There comes a time when backwards compatible is more of a hindrance then not.
Finally, and perhaps this is a misperception of mine, I would think that most of the individuals using this software have access to the source code for the programs they use. So... they can recompile everthing. Not a trivial task, to be sure, but still possible.
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!
I would intrepet this as saying: If you have say a shared library that was compiled with 3.1.1 and you attempt to use that library with a program compiled with 3.2 then it won't work because the compiled results are not interoperable.
But you can simply recompile both parts using 3.2 and they will work fine. you don't need to change the source code.
I will never live for sake of another man, nor ask another man to live for mine.
Have you even entertained the notion that the Quake engine has a real bug?
How many times is the C++ ABI going to be declared stable before it actually is?
I would have much preferred sticking with 3.1's slightly-broken ABI than 3.2's supposedly-fixed at this point. There's only so many times entire distributions and toolsets can get rebuilt before packagers are fed up.
The API has been very stable, the ABI for C++ has had to change to meet a spec that was outlined for gcc 3.0. Anyway, the reason for this 3.2 release was to make the distributers happy. Almost every distribution that will come out shortly, sarge, RH 8, Mandrake 9, will all use this compiler.
Hopefully they will freeze the C++ interface for a long time and linux/bsd distributions will not have backward compatibility issues when upgrading GCC. THANK YOU SO MUCH to al the GCC developers/contributors.
Yeah, I've had older versions of GCC generate bad code on me, too, including 2.95.x and 3.0.x (especially compiling certain C++ code with -O3). It is my understanding that 3.2 fixes all that bad code genning; so, you really ought to go it a whirl.
Perhaps there was not much going on at this time, perhaps others felt it important, perhaps it is important. Can we please stop complaining so much; if you don't find the article important skip it.
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
"Without GCC, free *NIX systems would have nowhere near the importance they have now."
So let's celebrate by giving front page space to a version update!
"Derp de derp."
Agreed. I have noticed far fewer postings on here announcing the latest developments in free software. I was afraid slashdot was going mainstream and donned the corporate hat or something, passing up news of community acheivements.
Seeing news like this to be discussed and picked apart in a large forum is always a good idea in my opinion. GCC is important for the way my gentoo linux box operates, so yes, I'm VERY interested in these articles. This is news that lets me be aware of issues I may encounter in the future.
It seems to me people complained when an article was posted about Yet Another Kernel Release. I can understand those people weren't interested and may have had better sources elsewhere, but I found slashdot a great place to discuss these issues since the beginning.
Excellent news !! To the whole team of adicts and great programmers having contributed to GCC 3.2, a million thanks !!!.
So I guess Red Hat 8.0 is now just around the corner.
Wow, it is not a big deal when you consider that GNU/Linux is Open Source. If the news doesnt affect you then do not post. People that stuck with GCC 2.* can try a nice GNU GCC 3.* compiler now.
I will still wait until GNU/Debian/Linux comes with GNU GCC 3.* before trying code compiled with the latest Version 3 Compilers. =)
Congrats to the GNU Developers.
Pixels keep you awake!
Compile with optimization on -- visual glitches.
Compile with optimization off -- no visual glitches.
Ever heard of Occam's Razor?
Use overrated.. that way it is still marked as humor (even if poor humor), but has a low rating.
slashdot!=valid HTML
It doesn't have to be posted on the front page for you to be able to see it. Just go to the developers section of slashdot and read all the developer news there.
The world moves for love. It kneels before it in awe.
except being base for kernel, gcc 3.2 is a base for probably all new distros comming out.
Redhat is waiting, Mandrake is waiting....
So is this a frontpage material?
Definetly yes. It informs, very well on other topics, which are waiting for that gcc releasem not only on gcc.
Signature Pro version 1.13.2-3 release 83.5 beta3try7 after-breakfast edition
The primary reason appears to be conformance with the C++ standard.
Everything GNU is predicated on the gcc compilers -- which makes a major release of the compiler very pertinent to anyone who cares about free software.
And given that gcc 3.2 is released specifically for Linux and BSD distro developers, I'd say it's kinda important. ;)
All about me
in fact, redhat already has gcc 3.2-1 in their rawhide distribution
if you don't think a new version of gcc is worthy
of front page news go read salon.com.
Or maybe E! has a good chat room for ya.
It seems I was too busy in my work to miss this acronym. I know "API", but "ABI"? No, really, its no joke, I don't really know.
So, I look at www.acronymfinder.com only to find it could well mean "Acquired Brain Injury" or "Asociación de Bienestar Infantil (Association of Infant Well-Being, Guatemala)"
Some Mac site says: "An ABI is an "application binary interface" and describes binary-level conventions for applications running on a particular system". If that is what it is - why not just call it a "calling convention" (__cdecl / __pascal in Windows, __System in OS/2)?
[OT: I remember a flamewar with linux programmers about how calling conventions are "a broken concept" - as generally everything windows does and linux not is considered "a broken concept" - things like exception handling, and event semaphores (not that broken SystemV crap)...]
FOLDOC says, its "The interface by which an application program gains access to operating system and other services. It should be possible to run the same compiled binary applications on any system with the right ABI.". Now, why is that not an API? because of *calling conventions*? Duh. And to break the compiler for THAT...
There are some types of bugs that are exposed by higher levels of optimization.
They did not promise that they will keep the ABI stable. They only promised that they will try very hard to keep it stable.
It is not inconceivable that another bug will creep up unexpectedly and force them to change again.
// file: mice.h
#include "frickin_lasers.h"
Hmm, Sarge will have GNU GCC 3.2 and GNU GCC 3.2 produces faster running binaries huh?
Sweet!
Pixels keep you awake!
Hmmm... Just Mac OSX 10.2... but that's not that much is it?!
(Please read above with as much sarcasm as possible... thanks you!)
--- Nothing To See Here ---
This is important because it would be great if mingw interoperated smoothly with C++ libraries built with Visual C++.
They also promised that the ABI was finished in 3.0. In fact, that was one of the reasons given for taking so long in getting 3.0 out the door. Not a good track-record, IMHO.
Still, it will be good to get closer to standards-compliance. C++ has been standardized for four years, now, and fully compliant compilers are just now starting to appear. GCC has actually been fairly good compared to some (cough, Microsoft, cough) in adhering to the standard.
"Use overrated.. that way it is still marked as humor (even if poor humor), but has a low rating. "
That works too. (he's referring to my sig...)
It's a pain in the butt when I post something to be funny, but it's not clear if the moderator understood my joke or not. I can be a little obscure sometimes.
"Derp de derp."
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
Let's be a little fair. By "breaking interoperability" it means code compiled by the new C++ compiler will not link to code compiled with the old C++ compiler. To this I say big deal. Yes it is troublesome, but that is the price of C++ and has always been the price.
You cannot link C++ code between the Borland compilers, Microsoft compilers. Sun's 4.2 compilers are not link compatible with its newer C++ libraries either. That is C++. The latest standard had an opportunity to standardize name mangling but chose not to do so.
Instead the latest standard had the gall to change the semantics of C++ and add significant complexity to the syntax (std::, new[]/delete[] vs. new/delete, advanced template syntax, etc.). If you want interoperability, look to using extern "C" frequently, or use a different language.
call me stupid, I know about API's, but what exactly is an ABI ?????
Now Available for download! Mandrake 9.0 beta 2, compiled with GCC 3.2!
Err, well, nevermind.
You need to restart your computer. Hold down the Power button for several seconds or press the Restart button.
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?
It is exactly his point. Code *compiled* with a new compiler version (say a .so) ->*_SHOULD_*- be interoperable with code *compiled* with older compiler verions.
.dll's compiled with MSVC 4.2. Nobody needs to even recompile anything.
Things compiled with MSVC 6.0 works with
There's nothing special or great about source compatibility. It is a _requirement_ plain and simple. You're not supposed to change source code just to make them compile with several versions of the same compiler.
What we're talking about here is BINARY compatibility.
The fact that you must compile with -fno-strict-aliasing or else too much is optimized away implies that your program has aliasing bugs.
In other words, this is your program's fault, not gcc's.
Not that nobody has ever found bugs in gcc's aliasing support, but 99% of the bug reports against aliasing have turned out to be broken code that violates ANSI C aliasing rules
The 'user' doesn't notice. When you get the newest distro, everything interoperates & everything you compile from then on works like it's supposed to. Just like when using MS; *don't upgrade* if you need something (unmaintained)that won't compile in the new environment; 'cept in windows you don't upgrade if you have two year old specialized HW, because companies don't support their older produts if they think you might easily buy v2 w/xp drivers.(They already know you'll friviously upgrade the OS if you're looking for the newos drivers)
When 3.0 first came out, someone completely busted parts of the PowerPC (R6000) backend (IIRC).
Has anyone used anything newer than 3.0 for cross-compiling to PowerPC (kernel or not)?
"Sometimes the truth is stupid." - Lawrence, creator of Prime Intellect
Compile with optimization off -- no visual glitches.
OR
Bug in my code.
Bug in compiler.
Now try to misapply Occam's Razor on that. I've had many bugs that disappear with "-g" turned on. These bugs are very hard to find. The one I remember most was due to writing outside the bounds of an array allocated on the stack. With optimizations on, important stuff was overwritten.
I had one optimization related bug I could never locate. Gives me the creeps ever time I see that Makefile (I didn't write the code). I don't blame the compiler until I've issolated the problem and looked at the assembly code.
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.
Poor old mandrake,
8.2 came out just before staroffice 1.0, KDE 3 Mozilla 1 etc....
Now they've build Mandrake 9 on gcc 3.1, opps.
Why don't opensource project communicate things like this to distributions.
thank God the internet isn't a human right.
Where does the gcc 3.2 release stand in terms of fixing the linking speeds of C++ programs?
Headline: "Quantum rift in space-time will cause life on earth to cease in 48 hours! Details below..."
Slashdotter: "How is THAT news?!?!?"
For the last time:
Redhat's gcc-3.2-1 is NOT gcc-3.2 !!!
It is/was an early CVS snapshot of the next major gcc version, which will now become gcc-3.3.
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).
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?
I recall a month or so back there was some talk about one of the distributions (mandrake 9 maybe) being compiled/released with GCC 3.1. Is gcc 3.2 compatible with 3.1. If not, what does this mean for the distribution? Recompile with 3.2? Release as is? How does the politics on this work?
Yes, compiler bugs specifically.
Don't make me whip out the statistics on how many gcc bug reports are actually broken user code.
yeah.. but it's July, d00d...
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...
I'm not going to dispute the good points that others have made regarding specific optimizations, but...
I've had many bugs that disappear with "-g" turned on.
No, no, no. You didn't just turn off optimization there, you turned on debug mode as well. Debug mode is well known to do things that regular compiles don't -- including initializing variables to zero and the like. Most coders have run into situations where compiling with debug on works and without it doesn't, and they are amongst the more difficult bugs to stomp out. But they (generally) have nothing to do with optimization. I've seen bugs from compilers before, even in things as benign as loop unrolling.
Do not mix apples and oranges. No optimization != debug mode.
From what Im reading in the comments, there can be problems when upgrading compilers across ABI versions. Can someone either summerize the possible difficulties, or point to a place on the web where I can read about them. What I mean is: If I switch from gcc 2.9x to gcc 3.2, what will I not be able to do, and what problems can I expect
Im not here now... Im out KILLING pepperoni
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!
Obviously there's a bug, just a question of where. Linux 2.2 series had problems with later more aggressively optimizing versions of gcc (2.95 i believe). These were because of kernel bugs, not compiler bugs. Specifically, they were some assembler statements that were'nt optimization safe This has been fixed in the 2.4 series. The 2.2 based distros kept the older not-as-aggressive gcc 2.8 or egcs 1.1 around as kgcc just for the compiler, while all the userland code (which didn't have this bug) used gcc 2.9 series.
And occams razor doesn't seem to apply here. You're seeing a problem, and there one of two equally possible sources.
How long before Mandrake are planning to release 9.0 GCC 3.2 could do with a bit of wild time before use in a stable distribution.
And now for Macintosh as well! MacOSX uses gcc as standard compiler.
Well, given that they just released 3.2 and are working on 3.3, and therefore have still a long way to go until 3.11 (if they don't switch to 4.x before anyway), there certainly isn't much code compiled with 3.11 yet :-)
There may be some stuff compiled with 3.1.1 though.
The Tao of math: The numbers you can count are not the real numbers.
Some time back, I decided to try out GCC 3.0.1 (I think it was). I downloaded the code and ./configure'd it with what the configure script said was the option to add a suffix (with the notion that I'd end up with my 'default' compiler being "gcc" (GCC 2.95.3) but have the option of trying something with "CC=gcc3".
I did a "make bootstrap" and a "make install"...and ended up with two "gcc's" on the hard drive - no suffixes. It ended up causing a lot of odd problems due to compiled programs trying to link to both versions of the libraries and so on. Of course, there is no "make uninstall"...I finally managed to track down all the files GCC 3.0.1 had installed by hand and delete them, now my system works again...
I'd actually like to try out gcc 3.1.1, at least - any advice on getting it to coexist as an obvious, separate "option" from the default gcc, and will the same advice actually work for gcc 3.2?
Hacker Public Radio is our Friend
Are there any benchmarks anywhere that compares the speed of code generated by GCC 3.2, 3.1, 3.0 and 2.9x?
That would be interesting to see, especially on modern processors with SSE, SSE2, etc.
Real programmers don't comment!
:)
You're absolutely right, that's reserved for ass holes like you and anonymous cowards like me.
Real Programmers just *read* slashdot.
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
If C++ ABI is now declared stable does this
automatically imply that GCC is now fully C++
standards compatible? If not then what is
left to change?
Maintaining backwards-compatibility at all costs has its own disadvantages... I wonder how much of the disk bloat of modern Windows installations is due to code written to ensure that 10-year-old Win3.x apps, or 20-year old DOS apps, will still work?
libstdc++5 from cooker is compiled with the new gcc.
Unfortunately it breaks a couple packages that are presently in cooker. The latest kde for instance.
Use /path/to/configure --prefix=/usr --program-suffix=SOMETEXT and you will end
up with a binary installed as " /usr/bin/gccSOMETEXT ".
This works.
42. Easy. What is 32 + 8 + 2?
If you have no insight whatsoever into the internals of a system -- such as is the case when viewing the inner workings of the universe from a pre-Einstein perspective -- then Occam's Razor can indeed prove useful.
But when you are told by people who understand what's going on inside what are the implications of failures appearing when compiling with certain optimizations enabled, then Occam's Razor no longer applies in the way that you think.
In fact, it applies in the exact opposite way, to wit:
A compiler represents, compared to the vast amount of code it compiles, maybe .01% of the total code involved (compiler plus code compiled by that compiler).
(The GCC compiler probably represents much less than that.)
Testing the compiler includes making sure it "correctly" compiles a substantial portion of the target software.
If the compiler offers an optimization that end users can turn on, one which is carefully documented and at least moderately well-tested, but that is known to expose bugs in the code it is compiling, yet has not been found to itself have a bug when enabled while compiling a substantial portion of the code...
Otherwise, one would presume a much larger body of software would fail in ways that are easy to track down to a compiler bug (especially in GCC's case, where the compilation phases are so transparent via RTL dumps and the like) when that optimization was enabled.
Especially in this case, where the kind of application bug is of a type that was widely deployed due to a combination of factors, even though I know the internals of GCC argue pretty strongly for the ability of a bug in the optimization being discussed to hide most of the time and still bite a few applications, I'd tend to lean, based on what you've said, towards a 75-25% likelihood of application bug versus GCC bug in this particular case.
In short: general rules are very useful, but they cease to apply to the extent specific information is available.
Practice random senselessness and act kind of beautiful.
Yes, but this switch wasn't necessary with 2.95, but is with gcc3. Technically it could be a problem in the code, but someone I know that is extremely familiar with assembly langauge looked over the output and compared the ASM output of gcc3 to gcc2's output and discovered what he considered to be errors in gcc3's output. Plus I know for certain that it generates int->float float->int "wrong" in certain circumstances, well maybe not wrong, but certainly less desireably than gcc2's output.
Hopefully it will compile without any major problems, unlike releases 3.0 and 3.1. I have yet to successfully compile GCC 3.1 on Solaris running on an Ultrasparc. I had few problems with 2.95.3.
-Aaron
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
I might believe it was the code if every version of gcc didn't change the behavior drastically, plus the fact this code is compiled under MingW, MSVC, etc. so it's much harder for me to believe that...
Some redhat versions of gcc 3.0x for example didn't have this issue, but every normal release from gcc3 people directly I've seen this issue with. So, *shrug*. I dunno.
Compilers aren't my forte unfortunately.
right, guy.
i know the fucking saying, but take note of the real date. it is indeed, August, hence my use of August.
d00d.
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...
So is it stable under sun4u-solaris now? I've tried 3.0.1, my colleague tried 3.1, and we both had the same problem on our ultrasparc machines: it generates binaries that dies for no particular reason with segfaults and whatnots. Everything is dandy with 2.95.3.
READY.
#
Try putting "using namespace std;" at the top of your code.
Usually it's user bugs. For example, the problems with building the Linux kernel under gcc3 were due to bugs in the Linux kernel -- it built fine under gcc2.95 because gcc2.95 was nicer about allowing illegal constructs (at the expense of some optimization opportunities). GCC3 much more closely follows the exact specification, which allows for more optimization (since it can take advantage of certain things guaranteed by the standard) but also exposes many more code bugs. If you compile under -O0, you won't expose as many of your bugs.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Especially since this fact was announced weeks ago. Amazing skillz of foresight ya got there.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Have all the problems that arose in 3.0 regarding performance on AMD Athlon processors been resolved? memcpy() among other things were quite slow when compared to similar processors with GCC 3, and with GCC 2.95.
And if it does work - what exactly does it do?
I'm trying to speed up my GCC compile times.
Will this help?
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 was happy to see the new Athlon option, but it doesn't do me much good when very minimalistic code gets generated incorrectly...
Please post this minimalistic code fragment of yours here and I will show you your bug. Don't bother replying otherwise - you're just wasting everyone's time with unsubstantiated nonsense.
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.
Does VC++ have an ABI? Are they all compatible? Could I check by trying to link a VC++6 .lib to a VC++7 .exe?
I remember once running down a bug that would not reproduce in a debug version. It turned out to be a buffer overrun, where the overrun was only one byte. The debug version had some extra junk on the stack, and the extra junk got ovewritten without harm.
When I was at Microsoft, we would build three versions of Word: the "ship" build (full optimizations), the "debug" build (no optimizations, debug enabled, asserts enabled) and the "hybrid" build (full optimizations, no debug, but asserts still enabled). I still do this.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
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)
BTW, hi, EvilTypeGuy, thanks for the tab completion :)
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
But now I have to recompile every single C++ library on the system in order to make the new compiler truly useful.
Yet, at the same time, I want to be able to run my old C++ binaries and also want to be able to drop back to my older compiler if necessary.
The best way to accomplish this, I suppose, is to put the new libraries in their own directory and modify gcc 3.2's spec file to include a -L directive to the linker to reference those libraries at link time and a -rpath directive at link time so that the resulting binary references that directory at runtime.
The other options I thought of involve either renaming the libraries (thus requiring manual intervention when compiling any package that would refer to the libraries by their "old" names) or changing their major version number (surely a serious abuse of the purpose of the major number! And it would cause problems when linking using the old compiler anyway). Neither of those are very palatable.
Anyone have better ideas on how to do this?
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
Mac OSX is based on C and Objective-C, if I recall correctly. Isn't the C++ ABI somewhat different than the Objective-C one, given the dynamic properties of the later?
(-:Stephonovich:-)
"Who needs reincarnation when we've got parallel universes?" -Me
When I tried out GCC 3.1 I just installed the new libstdc++ rpm alongside the old one, removing the old libstdc++-devel of course.
Worked fine for me, although I'm not sure if that was the wisest thing to do.
True... and Apple actually mentioned that developers shouldn't use C++ (but then played that down when the C++ Developers started complaining). Still there's quite a bit of Darwin level stuff that uses C++.
--- Nothing To See Here ---
Just out of interest, who else actually supports this "multi-vendor standard" C++ ABI? GCC does, but I've not seen anything much from any of the other major compiler vendors.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
So what else do we use? Borland is dead, VCC is MS crap, do we pay for Sun's CC or something? Really, I am interested having just got back into C/C++ I'm using gcc on 4 platforms for its portability and after being disgusted at how huge VCC code is and how old Borland is.
#include <sig.h>
Apple does use C++ internally, yes. However, Apple is careful not to expose C++ interfaces. That's precisely because of the danger of the C++ ABI changing.
The one exception is IOKit. It uses a specific subset of C++; it's believed that ABI stability will be easier with that subset than with the full language.
Its not that bad. I have upgraded from 2.96 to 3.0/3.1 a while ago. You only need to recompile the C++ libraries that you are going to be linking against. So only the libraries that you develop with. I discovered that there weren't that many. As well most of the libraries has new versions available anyway so it's a good reason to upgrade.
GS
>When will they understand that breaking interoperability is not the
>way to go forward? The reason MS Windows is where it is now is that
>you don't have to replace/recompile all your software every few
>months.
>
>
Given the choise of breaking software packages and recompling or ending up with crap like Outlook and the rest of the Virus tranfering/breeding crap Microsoft creates, I say break the software.
No, thank you for helping me get started down the coding path of C. My tab completion wasn't that great anyway, sure it's nice, but others have improved it since then I'm sure.
I raised this via the mailing list a few months back - some emails were traded but nothing has come of it.
Many packages are signed these days - it virtually guarantees that the code you are downloading has not been modified by any third parties. You all remember the irssi , BitchX and openssh incidents right?
Trojaned gcc, anyone?
No, I did not read the f***ing article!
in 5 years or less.
It is far too labor and capital intensive to build and maintain a high quality optimizing compiler these days.
No one makes serious money on compilers anyway.
The real money is in the hardware.
Does anybody know of a webpage that provides examples/scenarios where specific gcc optimizations make a difference? A search on google was futile. Most webpages simply cut-n-paste from the manpage.
For optimizations that are not turned on with -O3, it must be true that there are 'tradeoffs'. An exposition of these tradeoffs with examples would be great.
I've had the pleasure of using KAI C++ a few times now and I'm really impressed. It performs well on almost all of it's supported platforms, it's close to fully compliant with the ISO C++ standard (as close as GCC 3), and it's the only compiler I've used that I haven't yet found a bug in. The only downside I've noticed is that compilation speed isn't so great, particularly with heavily templated code (e.g. ACE & TAO).
I've played with linking VC6 libs to VC7 exes with little success. There seem to be problems with MFC, ATL, as well as std::string. So if std::string in in your interface, you'll most likely get runtime errors. If you're lucky you'll get link errors. Cross-linking MFC or ATL code built with VC6 and VC7 does not work. Microsoft has documented most (if not all) of this.
Obviously binary compatibility was not a high priority for them, kind of like gcc...
Does it improve the runtime or compiling-time performance? All I see are just some trivial bug-fixes and incompatability with gcc 3.1.
I'm wondering if somebody really wants to upgrade to it...
If you do abit more reading wou'll find out that the purpose of the gcc 3.2 release was to "fix" the ABI. gcc 3.1 was the one that were supposed to have a stable C++ ABI, but bugs were found, fixed and released as gcc 3.2.
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.
:-), XFree 4.2.0, QT 3.0.5, KDE 3.0.2, Mozilla 1.1b etc etc... So it's more that you need to compile everything with the same optimization.
I've compiled everything on my machine wih gcc 3.1.1 with -march=athlon -mmmx -m3dnow -O2 and I have never ever had an segfault.
This includes: kernel 2.4.19 (I edited the makefile
The "new" C standard??? All the type-based aliasing restrictions have been in C since the 1989 standard!
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.
That's "new" as in 1989 when ANSI adopted the standard for C. Yes folks, these aliasing rules have been around for 13 years now.
Why is it that most C programmers don't know about them? I don't know. But producing compilers that default to letting broken code get away with it can't help the situation.
All the GCC 3.x releases attempt to adhere to the same C++ ABI standard. It was developed for IA64, but GCC use it for all platforms. Intel and HP both have compilers (for IA64) that attempts to implement the same standard.
However, bugs were found in the implementation of the ABI standard in GCC 3.0 and 3.1. They had two choices, declare the bugs "the new GCC standard" and screw interoperabilitty with other vendors, or fix the bugs. They choose the later.
So yes, it is the GCC developers "fault" for writting bug in the first place. However, the bugs were somewhat esoteric (the Intel test suite didn't find them), and the standard complex. As a programmer, I won't blame anyone for writting buggy code. Only for not fixing the bugs.
Also note that "most" C++ code won't be affected, however the GCC developers can't really say "link, and hope for the best" when they know some legal constructs will be incompatible.
What matter is what the people paying for the GDB development are doing.
VisualC is known to emit different code in debug mode, I'm not sure that gcc does, it just dumps vast amounts of symbol data into the assembler pass. It shouldn't affect the runtime at all.
Note: non -g builds still contain some debug info and I don't think you can selectively strip just the extra data -g adds, otherwise there'd be no need to enable debug builds.
from the changes page :
"
Relase Notes.
See this message for a list of bugs fixed in this released.
"
There is stopped reading. I guess it's needs an other release before the syntax is correct.
And Bugs discovered in MSVC4.2 are still in MSVC6.0. Maintaining backwards compatibility to a broken interface benefits noone.
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.
There are a lot of things that should be a certain way. When it gets interesting is when you have conflicting "shoulds", and these are the questions gcc developers need to solve. The gcc development team don't need slashdot to tell them that binary compatibility is useful.
What GCC tries to do since 3.0 is to implement a common multivendor C++ ABI standard that is defined here :a tely, both GCC 3.0 and 3.1 had errors implemeting this standard. 3.2 is the latest try to fix all known ABI errors. However this does not guarantee that there are no other errors, and if there are any, future versions of GCC may be once again be modified such that they more closely adhere to the standard, even though this may break downward compatibility to older GCC versions.
http://www.codesourcery.com/cxx-abi/
Unfortun
The idea is that once other vendors switch to the standard C++ ABI, you will be able to mix C++ libaries compiled by compilers from different vendors. So for, beside GCC, Intel and HP are working on compilers implementing the common C++ ABI. However, given that there is no official testsuite yet verifying the adherance to the standard, no one can really be sure to fully implement the standard.
Other vendor compilers that have their own C++ ABI have a much easier task. For them, the standard is whatever previous versions of their compiler implemented, and they only have to make sure that new versions are compatible with the previous ones.
In all of your messages, you seem to be talking in a rather generic way about GCC3, and you do not mention what version you had problems with.
Especially regarding Athlon support, this can be very important as early GCC 3.x versions had Athlon specific bugs, but 3.1.1 or 3.2 should be much better in that regard.
So if you haven't already done so, I would really recommend you to redo your compilations with 3.1.1 or 3.2 and Athlon support, and see if the program still crashes or behaves differently now.
Technically it could be a problem in the code, but someone I know that is extremely familiar with assembly langauge looked over the output and compared the ASM output of gcc3 to gcc2's output and discovered what he considered to be errors in gcc3's output.
If you give a compiler broken C (ie. C that makes bad aliasing assumptions), of course you can't trust it to give you correct assembly. Some of this breakage may only occur with optimizations enabled -- so be it, that's the name of the game.
Post a code snippet that illustrates a genuine bug, then we'll start taking you seriously.
Now that can't be a coincidence. GCC news with a Visual studio dot net banner. See top news at http://fredrik.rambris.com/ for a screenshot. Looks funny.
Thanks.
I am MuchTall
How about i686-pc-linux-gnu/libstdc++-v3/src/locale-inst.cc out of the gcc-3.2 source itself?
xgcc segfaults when trying to compile this on my Athlon XP 1800+. Without optimisation it works, but who wants a non-optimised libstdc++?