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!"

Comments

the other goodness

[fredopalus]

That's great, but i'm still waiting for a flow-matic front-end

Re:the other goodness

[fredopalus]

And APL!

Re:the other goodness

[stonecypher]

> That's great, but i'm still waiting for a
> flow-matic front-end

So get a Flobee.

Heh I wonder if it compiles the Linux kernel

[streak]

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.

Re:Heh I wonder if it compiles the Linux kernel

[Neon Spiral Injector]

I'm at work building it on a server that will go into production soon, my workstation, AND my machine at home.

As soon as it is done...let me look, oh crap out of disk space, okay, fixed that...I'll build some kernels with it. 2.4.19 for my work machines, and I'll try out the latest 2.5 for my machine at home cause it has a nice sound card only supported by ALSA.

Re:Heh I wonder if it compiles the Linux kernel

[Anonymous Coward]

Might I ask what kinda of soundcard that is? I'm just curious.

Re:Heh I wonder if it compiles the Linux kernel

[Neon Spiral Injector]

Might I ask what kinda of soundcard that is? I'm just curious.

Terratec EWS MT-88. That is MultiTrack 8 channels in 8 channels out. True 96kHz/24-bit sample rate/depth. I run it into/outof an Alesis 10 channel rack mount mixing board, using an 8 channel punch-in snake. The board outputs to Alesis M1 Active monitors.

I write custom synths/noise generators/filters/effects, that I'll be compiling with GCC 3.2. Ha! Kept it on topic. :)

Re:Heh I wonder if it compiles the Linux kernel

[SirSlud]

Let me go back to off-topic land. Do you sequence and produce under *nix? Or do you use *nix to make the sounds and go to Windows-land to produce it all?

Being a electro-music head myself, I've never seen much stuff in *nix that I could use in my music production ..

Re:Heh I wonder if it compiles the Linux kernel

[Neon Spiral Injector]

I do all my work in Linux. I've seen some audio tools, and the more recent stuff is starting to look "professional". But I'm a CLI guy myself.

I have two types of tools that I have written. When I first started messing with audio creation, I followed the usual Unix tool route. Read from the standard in write to the standard out. I wrote filters to do things like:

cat 16-bit-unsigned.raw | noise-gate 1024 > 16-bit-unsigned.raw~

To set all samples below 1024 to 0.

I basicly scoured the web for C implimentations of various digital filters and effects. Once I got the idea of what was going on I started to write my own.

I also have written tone generators for all the basic wave forms.

What I'm working with most now, is a program I call an audio render. I had used POV-Ray since the 0.5 release, and loved the scene description language (very C like). I thought it would lend itself well to generating a stream of samples rather than pixels. So far the results are very interesting. I'd like to release it at some point, but I used most of POV-Ray's parser, and some other bits of code. It is most definatly a derived work, even if it does something totally different. Unfortunitly POV-Ray's license is kinda restrictive in this respect. Besides it isn't ready for primetime yet, and the POV Team are talking about relicensing at GPL, so maybe I'll get it to a point where I think others could use it about the time POV gets GPLed.

Wow, I wrote a lot. Please go gentle on the moderation. :)

Re:Heh I wonder if it compiles the Linux kernel

[Neon Spiral Injector]

Oh, I got off on a tangent, and didn't answer one of the questions that well.

My friends are the ones who are muscians. They have their own tools and seem to use Windows or just dedicated studio hardware. I mostly make noise, I think they are calling it Intelligent Dance Music this week.

Most of my stuff comes from my head and is performed in code. If I don't like how something sounds I change the code. So I have to do little production work.

I use the inputs on the mixing board (along with it's mic preamps) when I need to aquire something from the analog world. Such as vocals from one of my friends (I have promissed I will not try to sing again).

I divide the vocal sample up into phrases that I can then "render" into the final output.

One thing that is nice, is to render into an 8 channel audio file, seperating vocals or other parts that are very discrete so I can get a rough idea at what levels I should mix each channel using the analog slides. I can just loop the track or selection and sit there and tweak until it sounds good, then look at the values on the sliders to try in a final 2 channel rendering.

So to simply answer you question. I don't sequence or produce in the standard definations of the words.

Oh well who cares about the moderation, I'm talking about something I enjoy. :)

Re:Heh I wonder if it compiles the Linux kernel

[Anonymous DWord]

Oh well who cares about the moderation, I'm talking about something I enjoy. :)

This is why I read Slashdot. Seriously.

Re:Heh I wonder if it compiles the Linux kernel

[cduffy]

Heh I wonder if it compiles the Linux kernel ... But my guess is that it doesn't.

If that's the case, it's almost certainly the kernel that's broken (again), as opposed to the compiler.

Breaking interoperability... again???

[Drogo Knotwise]

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.

Re:Is this front page material?

[paladin_tom]

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.

Finally, ABI stabilization. Now about optimization

[eviltypeguy]

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...

Re:Breaking interoperability... again???

[TheSunborn]

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

Re:Breaking interoperability... again???

[Anonymous Coward]

That means that RedHat can now release Red Hat Linux 8.0, complete with GCC 3.2

Re:Gentoo 1.4?

[Anonymous Coward]

wtf is a gentoo?

and please, don't emerge your gentoo with me around.

compiles FreeBSD great

[Anonymous Coward]

GCC 3.2 works great when compiling FreeBSD.

Re:Breaking interoperability... again???

[streak]

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.

Re:Breaking interoperability... again???

[Anonymous Coward]

No, he isn't misreading it. The ABI has changed, this is nothing to do with compiling code.

Re:Translation:

[streak]

Real programmers don't comment!

Heh..Like to keep your job?
Or are you just planning to be the sole maintainer for the life of the code? =)

API _FINALLY_ Stable?!

[mfago]

So when will the distros catch up? Time for them to finally move to 3.x!

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.

Re:API _FINALLY_ Stable?!

[slaughts]

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.

What about binary-only packages

[dusanv]

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...

Re:What about binary-only packages

[Anonymous Coward]

The C ABI is stable. Any commercial distribution will also have compatability libraries for old code. But commercial applications should use this compiler as it will be used in all the upcomming distros. Maybe even slackware will move over.

Re:What about binary-only packages

[paladin_tom]

I believe that most (GNU/)Linux and *BSD systems include both a 2.95.x and 3.x version of GCC, so that you can compile software written for both.

Furthermore, compiles programs (games/commercial software) depend on shared libraries (*.so.x.y.z, the equivalent of Windows DLLs), which are separate from compilers. Again, you can have two or more versions of a shared library (ie. /lib/glibc.so.5.0.9 and /lib/glibc.so.6.2.1) on your system, so that you can run programs that need either.

Re:What about binary-only packages

[Neon Spiral Injector]

Keep your old libs around. But that is why I don't like binary code, cause I have to maintain seperate revisions of libstdc++.

Re:What about binary-only packages

[Stonehand]

If you're using such software and it's dynamically linked, you could do the following: (as long as it's not SUID/SGID...)

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 /etc/ld.so.conf unless there aren't going to be newer versions of these libraries that recompiled programs will use...

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.

GCC3.2 and GDB compatibility

[Anonymous Coward]

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.

Re:GCC3.2 and GDB compatibility

[Anonymous Coward]

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.

Re:GCC3.2 and GDB compatibility

[Amazing Quantum Man]

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.

<HUMOR>
Darn that Microsoft! You can't even debug Linux code properly without needing an IE patch!
</HUMOR>

Re:GCC3.2 and GDB compatibility

[davechen]

I just want to know how to look at the contents of my STL vector in gdb.

Re:GCC3.2 and GDB compatibility

[cduffy]

Careful. Embedded systems companies pay for a lot of gdb's development (and quite a bit of linux kernel development, and quite a bit of... well, assorted other stuff). Many of the developers thus care about embedded support because their jobs (and thus their ability to continue to get paid to work on gdb) depends on it. In any event, their focus is understandable -- they're scratching their own itch (or rather, that of their employers), and a Good Thing to those of us (and there're more than you'd think!) doing embedded work professionally.

Re:Breaking interoperability... again???

[be-fan]

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.

Re:Is this front page material?

[Pxtl]

Yes it is - as a coder, finally having stable C++ compiling is a big, big deal.

Re:Breaking interoperability... again???

[taeric]

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.

Thank God!

[Da Masta]

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!

Re:Thank God!

[chill]

You have patience. I broke the 1.3 CD I downloaded into small pieces after 2 days of fighting with it. I applaud your ability to last a whole week.

Re:Thank God!

[delta407]

Go home, log in as root, and:

# emerge rsync
# emerge -e world

Give it some time to crunch, and your whole system will be recompiled by the time you get to a prompt again.

Re:Thank God!

[rizzo]

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.

Re:Thank God!

[oyenstikker]

No. Your whole system will have crapped out after 3 minutes with a compile error, just waiting for you to come back on Monday.

Re:Thank God!

[hyperstation]

i am using a gentoo 1.4b system at home, gcc version 3.2 2002-07-26 (prerelease), optimized for athlon. so far, mostly good. there was a hitch compiling Xfree86, but was easily fixed.

a few things don't work, but i like it so far. kde is a bit quicker (opinion, i don't have anything to back that up with) and the system seems pretty stable, w/ no crashes thus far, and most everything built with -O3.

Re:Thank God!

[hyperstation]

i really don't understand what is so difficult about installing gentoo. you follow the instructions and type the commands, and wait. if there's a problem, look on the forums. easy.

Re:Thank God!

[Florian Weimer]

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.

Re:Thank God!

[chill]

1.2a, yes. 1.3 freaked the system out with a ton of compile errors. It really didn't like my setup (SMP P-3, all SCSI).

KDE is where it seemed to die. Hopefully, all is well.

Re:Thank God!

[erikdalen]

As 95% of all stuff is made in C, you wouldn't have had much to recompile. On my computer 1 or 2 applications/libraries are made in C++. /Erik

Re:Thank God!

[fusiongyro]

I think the meat of the observation was that he didn't realize GCC 3.2 wouldn't be backwards-compatible with GCC 3.1, not that he didn't realize that Gentoo 1.3 was the development version.

Oh yeah, and it's real professional to kill backwards-compatibility on a sub-major version release. Just awesome as hell. That way all your users can upgrade without thinking about it and suddenly have to reinstall their whole system. No wait, they must be morons for doing this.

As a Gentoo user, I'm hoping the new GCC will remain happily package.mask'd out and I won't have to deal with it. It's going to suck when things start depending on it though. I'd would be nice to be able to continue using "emerge -up world" without worrying about all of my C++ libraries (nothing big, just QT and KDE, ya know) becoming moot.

Basically, I've been more disappointed by GCC's developers lately than any other group, except maybe for Mooix. Of course, "lately" in the GCC sense is about two years, and it's only been about four days for Mooix. But that's just my opinion.

--
Daniel

Re:Thank God!

[dvdeug]

it's real professional to kill backwards-compatibility on a sub-major version release.

3.2 is a major release. The C++ ABI had not stabilized yet, and this is the last change before making it permenantly stable.

That way all your users can upgrade without thinking about it and suddenly have to reinstall their whole system

All the major distributers (FreeBSD, Debian, RedHat, Mandrake, SuSe) and anybody else who bothered following the list knew about this. GCC is like libc; changing it can break everything, so most people just let the distribution handle it. Those who ride the cutting edge, and don't keep their eyes out for something like this, get what they deserve.

Re:Breaking interoperability... again???

[jwiegley]

Perhaps you are misreading it. Code compiled with 3.2 will not be interoperable with code compiled with 3.1.1.

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.

Re:Finally, ABI stabilization. Now about optimizat

[Anonymous Coward]

Have you even entertained the notion that the Quake engine has a real bug?

Re:Any good compilers out there.

[FooBarWidget]

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.

The compiler who cried wolf?

[Anonymous Coward]

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.

Re:The compiler who cried wolf?

[cburley]

How many times is the C++ ABI going to be declared stable before it actually is?

That's just like the "viewer response" I saw CNN airing sometime around 2001-09-13:

When will I feel safe again?

It's a nonsensical question, although you can take personal action to resolve your concerns, if you choose. (You can simply decide to feel safe, or to never feel safe again; you can decide to undertake the kind of in-depth study of C++ ABI issues and GCC's code base to determine whether it's stable, or to accept that it'll never be stable. These are all coping mechanisms. Nobody else can answer the questions for you.)

In the meantime, if you want to "stick with 3.1's slightly-broken ABI", then what's preventing you from doing that?

Re:The compiler who cried wolf?

[Ranger Rick]

As someone who works on a "distribution", I can say that it's not that simple. There's a *lot* of work that goes into fixing things that break on the move to new compilers, and into handling binary incompatibilities.

Apple has moved to GCC 3.1 with their new MacOSX release, and it's been a *real* pain handling the switch. The issue is not a matter of things that have been rebuilt to work with each other, the issue is maintaining backwards compatibility with old binaries. If joe sixpack built some package into /usr/local that uses C++, it will be broken when he upgrades... it's the same on every distro, unless you build things twice, or rebuild *everything*.

Re:The compiler who cried wolf?

[cburley]

The problem is not that they changed the ABI, it's that they keep saying "It will never change again!".

Ah, well, that's a separate issue. ;-)

Stabilized C++

[InodoroPereyra]

This is the *main* thing:

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.

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.

Re:Stabilized C++

[norwoodites]

In fact on ia64 you can use c++ code compiled with the Intel compiler and the HP compiler and GCC and it will be able to link which is a good thing and work (there are a few exceptions because the HP and Intel are know to have ABI bugs in them, they might get fixed soon though).

Re:Is this front page material?

[callmechowdaz]

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.

UltraSparc, Linux, and RAID1

[doorbot.com]

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?

Re:UltraSparc, Linux, and RAID1

[mroos]

Debian uses gcc-3.1 etc as binary names, you might tell GCC=gcc-3.1 or whatever in Makefile.

Re: UltraSparc, Linux, and RAID1

[Antity]

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).

Huh? Have gcc with exactly this name in your path (check with type -p gcc . This didn't work?!

Re:UltraSparc, Linux, and RAID1

[mroos]

I run Debian on Sparc because I want a decent, convenient and developer-friendly environment on Sun Blade 100. First I started to compile packages on Solaris but then I found it would take at least a week and probably even more to get a desktop system as good as Linux. Installing Linux took 1 day and made me hayppy much quicker.

Every compile, link, ... benchmark and every OS microbenchmark (unixbench, ...) was better in Linux except X speed and KDE responsiveness.

GCC 3.1 made quicker code than 2.95 on Ultrasparc II FWIW.

yes they will work

[Ender Ryan]

All your existing binaries will still work, you just won't be able to link against them when compiling with GCC 3.2. Most commercial apps are statically linked against whatever GUI toolkit they use (as for games, all Loki's games are), so you have nothing to worry about.

Re:Translation:

[lux55]

Hey, this guy sounds like just the guy I've been looking for. I've been trying to find somebody to make a few small changes to some old Perl scripts I have... ;)

Nice .sig!

Re:Is this front page material?

[NanoGator]

"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!

Re:Is this front page material?

[dattaway]

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.

Great News !!! So Red Hat 8.0 soon...

[Erik_]

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.

Re:Great News !!! So Red Hat 8.0 soon...

[mrobinso]

RedHat 8.0?
What, 7.3 isn't broken enough for you?

Re:Finally, ABI stabilization. Now about optimizat

[Zathrus]

Compile with optimization on -- visual glitches.

Compile with optimization off -- no visual glitches.

Ever heard of Occam's Razor?

Re:Is this front page material?

[zapfie]

Use overrated.. that way it is still marked as humor (even if poor humor), but has a low rating.

Re:Is this front page material?

[sehryan]

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.

Re:Is this front page material?

[justsomebody]

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.

Re:Breaking interoperability... again???

[Andrewkov]

These reasons probably included speed, ease of compilation/optimization, stability, etc.

The primary reason appears to be conformance with the C++ standard.

Re:Any good compilers out there.

[Neon Spiral Injector]

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.

Re:Any good compilers out there.

[FooBarWidget]

Then compile without debug information or use 'strip --strip-all foo'

gcc is the Foundation of Open Source

[ChaoticCoyote]

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. ;)

Re:Is this front page material?

[mz001b]

in fact, redhat already has gcc 3.2-1 in their rawhide distribution

Re:Is this front page material?

[chanceH]

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.

Sorry, stupid Q: What is an ABI?

[1015]

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...

Re:Sorry, stupid Q: What is an ABI?

[ndogg]

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.

Re:Sorry, stupid Q: What is an ABI?

[larry bagina]

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.

Re:Sorry, stupid Q: What is an ABI?

[maxwell demon]

ABI is more than calling conventions. For example, the layout of standard types is part of the ABI, but completely independent from calling conventions.

Change the order of real and imaginary part in complex<>, and functions using complex<> will break when mixing versions. Without the slightest change to the calling conventions.

Re:Sorry, stupid Q: What is an ABI?

[Matthew Austern]

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.

Re:Sorry, stupid Q: What is an ABI?

[Stonehead]

Hmm.. I remember this problem from another polymorph imperative language: what if a procedure has a LOT of parameters? Don't you quickly overrun the maximum identifier length then?

Re:Breaking interoperability... again???

[ndogg]

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.

Re:Translation:

[Skuggan]

Maybe he can write readable code,
rarely seen these days...

Re:Breaking interoperability... again???

[skribble]

And how much stuff was actually compiled with GCC 3.11?

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!)

Re:Gentoo 1.4?

[skidgetron]

not quite, you'll also have to recompile everything with 3.2. And you'll have to change some symlinks and such.

Re:Breaking interoperability... again???

[edhall]

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.

-Ed

Just compiled a kernel with it.

[Neon Spiral Injector]

Looks like it produces smaller code than 3.1:

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 .config files.

Re:Just compiled a kernel with it.

[mgessner]

Yes, but did the new one boot and run for at least as long as the old one?

It may be smaller because they left out a bunch of instructions that were necessary...

Re:Just compiled a kernel with it.

[Neon Spiral Injector]

No, I haven't reached 9 days yet. :) But it did boot just fine.

ABI ??

[jo-do-cus]

call me stupid, I know about API's, but what exactly is an ABI ?????

Re:ABI ??

[chill]

Application Binary Interface.

I think. :-)

Re:ABI ??

[Anonymous Coward]

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.

Re: ABI ??

[Antity]

call me stupid, I know about API's, but what exactly is an ABI ?????

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.

Re: ABI ??

[p3d0]

API is not Application-Programmer Interface: it's Application Programming (or Program) Interface; that is, the interface you use when you're programming an application.

Re: ABI ??

[Antity]

Yes, typo. sorry.

Re:Finally, ABI stabilization. Now about optimizat

[tlk nnr]

If -fno-strict-aliasing fixes the glitches, it could be an invalid assumption in the C code.

Read the gcc docu for the details: With the alias analysis ,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.

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?

Re:Breaking interoperability... again???

[Wolfier]

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.

Things compiled with MSVC 6.0 works with .dll's compiled with MSVC 4.2. Nobody needs to even recompile anything.

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.

Did they fix PowerPC bugs?

[mgessner]

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)?

Re:Translation:

[Zathrus]

Readable code does not document business logic, and the business logic that leads to the code isn't always documented anywhere useful, or (better yet) it changes and the original logic can't be found anymore.

So write readable code. And comment. They're inseperable necessities.

Unless, of course, you do want to maintain the code forever. Personally, I'd rather go off and write new, nifty stuff than maintain old, cruddy stuff forever (and yes, all the old code is cruddy by definition -- if you can't think of improvements to something then you didn't learn anything).

Re:Finally, ABI stabilization. Now about optimizat

[Anonymous Coward]

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.

Mandrake

[oliverthered]

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.

kde speedups ?

[jefe289]

Where does the gcc 3.2 release stand in terms of fixing the linking speeds of C++ programs?

Re: kde speedups ?

[Antity]

Where does the gcc 3.2 release stand in terms of fixing the linking speeds of C++ programs?

Isn't this rather part of ld(1) (binutils)?

Re: kde speedups ?

[norwoodites]

No it is not but the problem is part of glibc because it is the part that runs the ld.linux.so so it is there where it needs to fix the speed problems.

Re:Translation:

[pivo]

Readable code is no substitute for comments. Even if you can easily see what a method does, it doesn't follow that you know why it does it.

Doesn't compile glibc 2.2.5

[Neon Spiral Injector]

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).

Re:Doesn't compile glibc 2.2.5

[Neon Spiral Injector]

Sure enough, someone else had this problem with a CVS version of GCC 3.2.

Looks like Ulrich Drepper didn't think the patch that was proposed was quite right, and has his own.

Re:Doesn't compile glibc 2.2.5

[norwoodites]

I though the problem had been fixed in the cvs version of glibc?

Re:Doesn't compile glibc 2.2.5

[Neon Spiral Injector]

It may have been, but as you see, I'm trying to compile 2.2.5, not a CVS snapshot. As a matter of fact, they almost surely have been fixed in the CVS, as the patched I liked to had questions about if they should be committed the the CVS.

Re: Breaking interoperability... again???

[Antity]

"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?

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.

Distribution Releases

[jjv411]

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?

Re:Finally, ABI stabilization. Now about optimizat

[pivo]

There are some types of bugs that are exposed by higher levels of optimization.

Yes, compiler bugs specifically.

Re: Finally, ABI stabilization. Now about optimiza

[Antity]

Compile with optimization on -- visual glitches.

Compile with optimization off -- no visual glitches.

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.

Precompiled headers

[FooBarWidget]

Does anybody know when GCC wil finally support precompiled headers?

Re:Precompiled headers

[norwoodites]

3.4 likely, Apple will be submitting their precompiled headers (PFE) after 3.3 comes out.

Re:Precompiled headers

[Sinical]

A couple of people from Apple are working on adding this to the FSF distro: apparently they have it in the version they use, and it was up to 6x faster.

Dunno about a prospective release date. See the gcc mailing list for details.

Re:Precompiled headers

[Inoshiro]

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)."

What does this mean for OS X?

[frankie]

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...

Re: What does this mean for OS X?

[Antity]

AFAIK, the entirety of Jaguar is compiled with GCC 3.1 [google.com]. Replacing all the libraries with v3.2 is gonna be some mighty huge software updates...

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.

Re:What does this mean for OS X?

[Pius II.]

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...

Re:What does this mean for OS X?

[anarkhos]

Actually that's not true, ObjC makes up for a distant 3rd behind C and C++. Heck, all the drivers are written in C++.

This just goes to show that Apple cannot help but be behind when it comes to such things.

My worry is gcc bug fixes cannot be easily merged with 3.1. It's a real pain.

Re:What does this mean for OS X?

[anarkhos]

I'm sure Apple decided to use 3.1 based on the API being stable, so they've gotten the rug pulled from under them!

The problem isn't only system libraries which are based on C++ but their developer tools which use gcc 3.1. This means when Apple moves to 3.2 they will have to inform everybody that all their libraries will also have to be redistributed with their programs.

In the meantime I worry that bugs in 3.1 which are fixed in 3.2 will be difficult to merge with 3.1 which only Apple will be using. What a pain |-\

I'm not sure if drivers are effected because they use a limited C++ subset. If they are Apple will probably maintain 3.1 for a long time, even though they will be the only ones doing it |-\ Anyway, there is no telling if 3.2 is stable either!

Re:What does this mean for OS X?

[captredballs]

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.

Re:What does this mean for OS X?

[randombit]

This is really bad timing for Apple folks.

Nope. Various Apple people said on the lists that they were happy with 3.1.1.

Re:What does this mean for OS X?

[Arandir]

Maybe they're waiting for GCC 3.3 so they don't have to do all this work twice. Heck, if I were them I would wait for 4.1!

Re:What does this mean for OS X?

[PythonOrRuby]

Ahem.... Objective-C may not be as popular as C or C++, but popularity doesn't have a thing to do with the technical merits of a system.

Just look at Windows.

Apple isn't behind, they've just done things in a slightly different way than most people do it.

Re:What does this mean for OS X?

[anarkhos]

I think you better read my post again, I didn't talk about the abilities of ObjC. I happen to like ObjC, a lot (although I don't like Cocoa for various reasons).

So AHEM YOURSELF! (fucker)

Re:Finally, ABI stabilization. Now about optimizat

[Zathrus]

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.

Switching Compilers

[Catskul]

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

Re: Switching Compilers

[Antity]

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

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.

Re:Mandrake

[swv3752]

Beta 1 and 2 are built on 3.1.1, but the final 9.0 will be buitl with 3.2, and probably the rest of the Betas.

Re:Finally, ABI stabilization. Now about optimizat

[edhall]

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.

-Ed

Stable C++ ABI???

[Anonymous Coward]

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!

Re:Finally, ABI stabilization. Now about optimizat

[cant_get_a_good_nick]

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.

Re:Mandrake

[Anonymous Coward]

"Why don't opensource project communicate things like this to distributions."

They DO, if you only *listen*. This subject is extensively discussed on the gcc mailinglist, discussed by gcc developers and people from distributions. Of course, their decision is still *their* decision, but they knew gcc 3.2 would be around there really soon.

Re:Is this front page material?

[krokodil]

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.

And now for Macintosh as well! MacOSX uses gcc as standard compiler.

Re:Mandrake

[ryants]

In Mandrake cooker (which is the devel version of Mandrake), this appears in the changelogs of nearly every app:

* Thu Jul 25 2002 Gwenole Beauchesne
<gbeauchesne@mandrakesoft.com> 1.0.0-9mdk

- Automated rebuild with gcc3.2

Mandrake 9 will be based on gcc 3.2

Re:Breaking interoperability... again???

[maxwell demon]

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.

Re:Is that wise?

[ryants]

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.

Keep in mind that 3.2 is just 3.1.1 + minor ABI bug fixes.

(Sorta-kinda OT) - GCC3 and GCC 2.95.3 coexist?

[Dr.Dubious DDQ]

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?

Re:(Sorta-kinda OT) - GCC3 and GCC 2.95.3 coexist?

[Plutor]

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.

"Uninstalling" and "upgrading" becomes as easy as "for F in `ls -l /usr/local/* | grep '-> /usr/local/package/'`; do rm $F; done".

At the aforementioned job, the directory I installed to was actually /usr/local/package/version/architecture/, but I consider that overkill on my home machine.

Re:(Sorta-kinda OT) - GCC3 and GCC 2.95.3 coexist?

[FooBarWidget]

Use a different prefix! I have 4 different GCC versions on my system (2.96 and 3.0 both provided by RedHat, and 3.1 and 3.2).
I configure GCC 3.2 like this: ../gcc-3.2/configure --prefix=/usr/local/gcc32 [misc unimportant options here]

This way, *all* files will be installed in subdirectories inside /usr/local/gcc32. The binaries go to /usr/local/gcc32/bin, the libraries to /usr/local/gcc32/lib, etc. Removing GCC is as easy as rm -Rf /usr/local/gcc32

To make sure GCC will work:
- make a symlink /usr/bin/gcc32 to /usr/local/gcc32/bin/gcc
- add /usr/local/gcc32/lib to /etc/ld.so.conf and run ldconfig

I just installed GCC 3.2 an hour ago, but I installed GCC 3.1 using the same method (except that the prefix is /usr/local/gcc31) and everything work just fine; no problems whatsoever. I successfully compiled an entire GNOME 2 system using GCC 3.1.

Benchmarks of generated code?

[hattig]

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.

Re:Benchmarks of generated code?

[FooBarWidget]

I don't have any links to comparisons (I know they exist), but I can tell you this: bzip2 is 25% faster when compiled with GCC 3.1.0 compared to bzip2 compiled with GCC 2.95.2, on a Pentium 233 MMX.
GCC 3.1.1/3.2 optimize even better.

Hints for compiling gcc-3.2

[Anonymous Coward]

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

C++ stability

[Compuser]

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?

Re:C++ stability

[FooBarWidget]

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).

Re:C++ stability

[Anonymous Coward]

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!

Re:C++ stability

[norwoodites]

gcc is not fully standards compliant when it comes to c++, this is being fixed via a new parser.

Re:Breaking interoperability... again???

[poot_rootbeer]

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?

Re: (Sorta-kinda OT) - GCC3 and GCC 2.95.3 coexist

[Antity]

I did a "make bootstrap" and a "make install"...and ended up with two "gcc's" on the hard drive - no suffixes.

Use /path/to/configure --prefix=/usr --program-suffix=SOMETEXT and you will end up with a binary installed as " /usr/bin/gccSOMETEXT ".

This works.

Re:Finally, ABI stabilization. Now about optimizat

[cburley]

Ever heard of Occam's Razor?

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...

...then Occam's Razor actually suggests the source of a bug in a specific application that fails when compiled with that optimization enabled is the application itself, not the compiler.

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.

Re:Finally, ABI stabilization. Now about optimizat

[eviltypeguy]

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.

GCC 3.2 and Solaris

[AaronW]

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

Re:Finally, ABI stabilization. Now about optimizat

[eviltypeguy]

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.

Re:Any good compilers out there.

[dustman]

On some areas, GCC is faster, while on other areas, GCC is slower than Intel C++. But all in all, GCC is quite good.

I'd like to see a real benchmark of this. The same exact thing is said about every language/compiler by its proponents (think java vs c/c++, etc)...

Re:Finally, ABI stabilization. Now about optimizat

[eviltypeguy]

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...

Does it work with sun4u-solaris now?

[MagerValp]

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.

Re:Does it work with sun4u-solaris now?

[Anonymous Coward]

Some guy on the subway today told me that GCC 3.2 works correctly on SMP Sun boxes. But then he dropped his pants. You decide if the information is credible.

Re:Does it work with sun4u-solaris now?

[ShawnX]

Works fine, *DO NOT USE GNU BINUTILS* use the native linker/as/ld etc. Works fine even built MySQL 64bit =)

Re:Breaking interoperability... again???

[AxelTorvalds]

Have you read the C++ spec?

Try putting "using namespace std;" at the top of your code.

no

[Trepidity]

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.

Re:no

[pivo]

because gcc2.95 was nicer about allowing illegal constructs

That's not a very convincing argument, IMHO. The idea of a compiler allowing illegal constructs that may or may not work under different optimization levels does not sound to me like anything other than a compiler bug (or misfeature at best.)

Huh?

[devphil]

Yeah, good thing I saw this coming.

Especially since this fact was announced weeks ago. Amazing skillz of foresight ya got there.

Re:Any good compilers out there.

[FooBarWidget]

I based my claim on a comparison I found on the GCC mailing list a while ago. But I don't remember the subject of the email. You may want to search through the mailing list.

Athlon performance?

[evilpaul13]

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.

An answer from a maintainer

[devphil]

Hi. I'm one of the hundred-odd GCC maintainers.

When will they understand that breaking interoperability is not the way to go forward?

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...

Re:An answer from a maintainer

[Arandir]

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.

Your explanations make sense, but they don't address an important point. Perhaps I should put on my hip boots and wade thru your archives.

Why are you not deferring ABI changes to major (or relatively major) releases? Why the breakage in 3.1.1? If you find a bug in the ABI, will you break it in 3.2.1 or wait until 3.3 instead?

I'm thinking to myself that a lot of these problems could have been avoided by spitting gcc into a stable and a devel branch.

Re:An answer from a maintainer

[sproctor]

maybe you misread the story or I misread your post. 3.1.1 is abi compaitible with 3.1 (I think that's why it was released). 3.2 broke compatibility with 3.1.x. 3.2 seems to be basically 3.1.1 but with a different C++ ABI on some corner cases (like phil just said)

Re:An answer from a maintainer

[Arandir]

Aaah! This makes more sense now.

Re:Any good compilers out there.

[FooBarWidget]

I just did a comparison between 2.96/3.0 and 3.1/3.2. The executables produced by 3.1/3.2 are about 40% smaller (with debug information).
I only tested this on one program though, so I'm not sure wether all executables will be 40% smaller.

works with Gentoo i686 glibc-2.2.5 gnome2

[BoydWaters]

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.

Visual C++ ABI?

[Anonymous Coward]

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?

Re:Visual C++ ABI?

[FooBarWidget]

*All* compilers have ABIs. ABI is the Application Binary Interface. MSVC++ is not nearly as standards compliant as GCC 3.2, so the answer on your 2nd question is no. I don't have an asnwer on the 3rd one.

-g and bugs

[steveha]

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

Re:-g and bugs

[pthisis]

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.

Here's an experiment: build POVray, gzip, oggenc, or LAME both with and without "-g" (but with the same optimization flags). Benchmark it. There just won't be any difference, even in those very compute-intensive programs.

By shipping a "ship" build that isn't exactly the same as the one you develop and tested with, you're just asking for trouble. You should build and test with the same optimization flags you intend to ship with, and you should ship with the same debug info you tested with.*

It's also a good idea to make most assertions lightweight enough that you leave them in the production build--remember the old quote about turning off assertions for a production build being like removing your seat belts for the big race. It's often handy to have some major, slow, intensive assertions during testing, but many of the smaller "can't happen"-type assertions can save user data and pain if left on in production.

*Yeah, sometimes you may want to turn optimization off for a run or two if you're tracking a particular bug.

Sumner

Re:-g and bugs

[steveha]

The builds released to the testers and customers were always the "ship" builds! How did you ever get the idea that it was anything else?

The "debug" build had no optimizations. This makes the single-stepping work much more predictably. The "hybrid" build had all the same optimizations that the ship build had, but had assertions and any other debugging framework still compiled in.

Testers would find bugs in the ship version, and developers would try to reproduce them in the debug version. On rare occasions, the bug would not reproduce in the debug version, and the hybrid version would be used to try to run the bug down.

I thought it was really cool when the MS C compiler got the ability to put all debugging info in a separate file. Then you could have a ship build with debug information, and you could single-step it, and it was the same file that the customers would get. Sometimes, due to optimizations, the single-step behavior was odd, but that is a small price to pay for being able to actually look around inside the exact bits that ship to testers and customers.

It's also a good idea to make most assertions lightweight enough that you leave them in the production build

This is an interesting idea. I suspect that usability advocates like Don Norman would shudder at this. The assertions were always things like "pPAP != 0"; what would a customer make of such things? I do think it is worthwhile to have a logging capability, such that a customer could turn logging on and provide you with a log telling you what went wrong.

Who made the old quote about turning off assertions, and where did you read it? I'm interested.

steveha

Re:-g and bugs

[pthisis]

It's also a good idea to make most assertions lightweight enough that you leave them in the production build

This is an interesting idea. I suspect that usability advocates like Don Norman would shudder at this. The assertions were always things like "pPAP != 0";

What's more of a usability problem, a controlled crash with an error message or silently eating your data without hope of recovery? Early failure is a big point with usability experts. You can easily wrap the assertions as needed; instead of #include , create a "test or print" macro/function that prints a more readable error message.

Who made the old quote about turning off assertions, and where did you read it? I'm interested.

I got the quote wrong. It's C.A.R. Hoare, who wrote "A programmer who turns off assertions in live code is like a pilot who wears a parachute while walking on the ground but removes it when he gets in the air". I think I first read it in Kernighan and Pike's excellent book, "The Practice of Programming", but it's widely cited.

Hoare is one of the first to propose axiomatic methods of program analysis (and he worked extensively with Wirth on the design of Pascal).

He is also credited with:

"inside every large program is a small program struggling to get out."

and

"There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies."

Sumner

Re:-g and bugs

[steveha]

What's more of a usability problem, a controlled crash with an error message or silently eating your data without hope of recovery?

Sorry, not with you on this one. Controlled crash and good error handling is obviously what you want. But assertions don't get you that! They just alert you that something unexpected is going on, with a cryptic message.

Because assertions are not included in the ship version, you can somewhat go nuts with them, not worrying about them bloating the size of the app or slowing down time-critical loops. I don't want to feel I have to be careful where I put asserts; I like knowing they won't bother the actual users.

I do recommend having robust error handling, but I don't think exposing asserts to the user is a good way to do that. I think checking return values from functions, and handling errors intelligently, would be more valuable than either throwing cryptic messages at the user, or laundering the assert messages into something like "something odd is going on; be afraid". (I am not one of the guys who claims that you save time by not checking return values!)

The way assertions were done when I worked on Word, an assert would pop up a dialog box. If you ran the binary under a debugger, you could trivially break in and have a look at the variables in the function that asserted. But the dialog box, while great for developers, was not user-friendly. Especially if the assert was in a loop and happened a lot!

About the quote about shipping with assertions in: there is a similar quote about shipping with bounds-checking enabled for arrays. In The Elements of Programming Style, Kernighan and Plaugher made a comment along the lines of "only disable bounds checking when it is important to get the wrong answers more quickly."

steveha

Re:-g and bugs

[pthisis]

Sorry, not with you on this one. Controlled crash and good error handling is obviously what you want. But assertions don't get you that! They just alert you that something unexpected is going on, with a cryptic message.

The message doesn't have to be cryptic, though in some cases it's tough to avoid. That's because....

I don't think exposing asserts to the user is a good way to do that. I think checking return values from functions, and handling errors intelligently, would be more valuable
...assertions don't handle the same cases as return value checking. They're (apologize for the buzzphrase) completely orthogonal. Checking the return value (which is obviously almost* always required) helps verify that the function's output was as expected. Assertions are a primitive form of programming by contract, and are primarily a way of checking that the function's input was as expected.

Assertions can catch the sorts of errors that happen when no function returns error but the aggregate behavior of many functions puts things in an inconsistent state.

Sure, it's often more cryptic to say "CircleRadius < 0; aborting". Good assert macros can help that to a degree. But fundamentally, a function knows much less about who it was called _by_ (ie, the case where assertions are helpful) than who it called and why (the case where return value checking is helpful).

Assertions can also be used to verify postconditions after another function is called that don't show up in the return value.

Think of it this way: if assertions didn't help catch things, they wouldn't be used at all. If your program doesn't need them for some reason (you have a static contract checker or something), that's cool. But if you use them in development, why not check for the same error conditions in the live deploy? A few may be far too slow, but most assertions aren't and would be helpful in the live deploy.

Also, look up "programming by contract" some time.

Sumner

*I say "almost" because if you aren't going to take a different action based on the return value then it's not worth checking. Example: you have a systemic failure that requires system exit. You fprintf an error message and exit. If there's no alternative channel to alert the user (e.g. it's before disks have been mounted), there's no reason to check the return value of fprintf since there's nothing you can do to recover.

Re:Any good compilers out there.

[randombit]

I'd like to see a real benchmark of this. The same exact thing is said about every language/compiler by its proponents (think java vs c/c++, etc)...

here is a link to some comparisons I made. It's kind of out of date, GCC 3.0.4 vs ICC 6.0 vs KAI C++ 4.0e. I'm using 3.1.1 as my usual compiler nowadays but I haven't gotten around to updating this.

Basically the poster you responded to is right. ICC won on some things, GCC won on others. And, for the most part, KAI C++ kicked the hell out of both of them. The comparison was integer-heavy code with lots of tight loops on a 1.4 Ghz Thunderbird.

Apples and oranges

[devphil]

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.

Re:Apples and oranges

[Rob Riggs]

Vendors already have methods in place for dealing with multiple versions of a library installed; this will be nothing new to them.

This is true of OS vendors, but for end users and third-party library vendors this is still a nightmare. Many of us end-users rely on commercial, closed-source C++ libraries for our applications. As compiler and core library ABIs change, each vendor has to choose which ABI to support. The end users who chose a suite of commercial libraries supporting GCC only a couple of years ago are quickly finding themselves in unsupported enviroments because vendor A is still using GCC 2.95.x, vendor B has chosen GCC 3.1, and vendor C announces that in 3 months their product will support GCC 3.2, deprecating the version that supports GCC 2.95.x.

Applications that rely on all three vendors' libraries are in a heap of trouble.

What is being done to address this problem?

Re:Finally, ABI stabilization. Now about optimizat

[Bill Currie]

I guarantee there are aliasing bugs in Quake (whether they're still there in Twilight is another matter). How am I so certain? I fixed several in QuakeForge (another Quake project). I'm beginning to think there are some more due to some weird issues we're getting with our quakeworld server where everybody is complaining of disappearing entities (ie, it doesn't matter which client they use).

BTW, hi, EvilTypeGuy, thanks for the tab completion :)

A mess for those running old/current distros...

[kcbrown]

Suppose I have a system that uses an older compiler and I want to put gcc 3.2 on it. No problem as far as naming the compiler and such goes, that's the easy part.

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?

Re:Breaking interoperability... again???

[MonsterChicharo]

Hmmm... Just Mac OSX 10.2... but that's not that much is it?!

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?

No commenting?

[Stephonovich]

While it may seem macho, (geeko?) I would have to say that comments are the best thing going. I have a written small program, (whatrace.exe for DOS, whatracelinux for linux, (duh) and whatrace.cpp for source)maybe 400 lines or so, and even with that, comments have been extremely helpful, remembering what did what. I try to use meaningful variable names, (firstCompSpeed, to name one) instead of cryptic ones. Or were you just joking?

(-:Stephonovich:-)

Re:Gentoo 1.4?

[MonsterChicharo]

As in this picture

Re:A mess for those running old/current distros...

[Hitokage_Nishino]

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.

Re:Breaking interoperability... again???

[skribble]

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++.

Common C++ ABI?

[Anonymous Brave Guy]

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.

Re:Common C++ ABI?

[Matthew Austern]

who else actually supports this "multi-vendor standard" C++ ABI?

HP and Intel already have compilers that support it. (Remember that the ABI was originally designed for Intel's Itanium.) Other companies were heavily involved with the design, and may eventually have compiler that support this ABI if they don't already.

Re:Breaking interoperability... again???

[Matthew Austern]

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.

Why aren't GCC downloads digitally signed

[yem]

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?

Re:KAI C++

[randombit]

it's the only compiler I've used that I haven't yet found a bug in.

I actually found 3 or 4 bugs in it (back in the 3.4 versions). Which was a pleasurable experience in itself, because each time, they had a fixed version for me within 48 hours. That impressed me very much.

Unattractive release...

[d2002xx]

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...

Re:Unattractive release...

[Anonymous Coward]

GCC 3.2 is just a bug fix release to 3.1. It does not add any new features or optimizations. It's actually just the 3.1.1 code plus the ABI fixes. The new version number has been chosen because of the ABI incompatibilties.
As for deciding whether to use 3.2 or not, it may depend on what you have been using before.
If you have GCC 3.1x and you have C++ libraries, you may stick with GCC 3.1.1 until GCC 3.3 is there. This will postpone any incompatibility mess until you get something in return for it.
You you are using a pre 3.1 GCC version and you want to upgrade, you should absolutely skip 3.1.x and go to 3.2 right away.

Re:Finally, ABI stabilization. Now about optimizat

[fredan]

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.

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 :-), 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.

Re:Finally, ABI stabilization. Now about optimizat

[drj11]

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.

Not really...

[Per Abrahamsen]

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 "most people" are doing is irrelevant.

[Per Abrahamsen]

What matter is what the people paying for the GDB development are doing.

Relase Notes

[leuk_he]

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.

Re:Relase Notes

[skelf]

> There is stopped reading. I guess it's needs an other release before the syntax is correct.

People in glass houses...

Re:Breaking interoperability... again???

[mheine]

And Bugs discovered in MSVC4.2 are still in MSVC6.0. Maintaining backwards compatibility to a broken interface benefits noone.

you could call it a bug in 2.95

[Trepidity]

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.

Re:A mess for those running old/current distros...

[elflord]

Anyone have better ideas on how to do this?

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.

Re:Breaking interoperability... again???

[elflord]

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.

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.

Re:Finally, ABI stabilization. Now about optimizat

[cduffy]

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.

Visual studio dot net and GCC 3.2?!!

[frambris]

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.

Re:Finally, ABI stabilization. Now about optimizat

[netpixie]

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++?

Re:Please ignore me.

[Inthewire]

I Agree With This Post