GCC 3.1 Released

gergnz writes "Just popped into my inbox, GCC 3.1 released. There are many bug fixes over 3.0. "we focused more on quality than new features" Mark Michell. Here are the changes, and you can see a list of ftp servers here. This is the release I have been waiting for. I will now upgrade :-) Well Done to all involved!"

3.1?

[ObviousGuy]

Windows was at that level 8 years ago! Even VC++ is up to 7.0 now. Sheesh! Faster development with fewer bugs, my ass.

Seriously, though. Hopefully this takes care of all those niggling bugs that made 3.0 unusable. Maybe this will encourage everyone to jump from the 2.x tree finally.

Re:3.1?

[BigDaddy]

They could just do what Patrick at Slackware did and jump three or so version numbers in a single release.

Re:3.1?

[elflord]

Seriously, though. Hopefully this takes care of all those niggling bugs that made 3.0 unusable. Maybe this will encourage everyone to jump from the 2.x tree finally.

I think it has, and I think it will. There are a lot of very important bugfixes in this release, especially with respect to the C++ ABI. My bet is that this is going to be a distribution compiler.

Re:3.1?

[mickwd]

Mandrake's development release (Cooker) is already being built with GCC 3.1.

Re:3.1?

[jmv]

I have a complex (it uses lots of features) C++ program which compiled fine (after a couple tweeks) under 2.95.x and 2.96 but would crash when compiled with 3.0.x. I used to think it was my fault but it now works again with 3.1 so I guess 3.0.x was badly broken...

Re:3.1?

[jdennett]

It might be your fault, and it's just that neither 2.9x nor 3.1 shows up the bug. Or it might, as you say, have been a bug in 3.0.x. Without seeing the code, I can't say.

Re:GCC (any version) in a nutshell

[morbid]

How did you get to be +1 Informative with a troll of this kind? GCC's code generator has improved in leaps and bounds recently. It may not generate the fastest code on all platforms, but it generates reliable code that is good enough. If you really are interested in performance, a little bit of profiling and clever coding goes a long way.

Re:GCC (any version) in a nutshell

[L. J. Beauregard]

It seems that GCC generates rather simple-minded code and relies on the optimizer to make it fast. I've never had a GCC-compiled program that was not significantly faster when compiled with -O2.

And if -O2 is not enough, well, that's what gprof and inline assembly is for. GCC's inline assembly feature is unmatched by any compiler I've ever seen (though Borland's register pseudovariable feature comes in handy if used carefully).

Re:GCC (any version) in a nutshell

[Bert64]

"good enough" - just like windows, just good enough to prevent a mass exodus from the platform, but not good enough that you wont want the next version. Since when has inefficient code been "good enough" ? shouldn`t we be trying to get the best possible performance from existing hardware... not everyone can afford a faster machine every month.

Most Notable Improvements

[Sentry21]

Here's a short run-down of the improvements that really caught my eye this time around.

• Better PPC support (64-bit PowerPC GNU/Linux support in the backend, and altivec support with -maltivec)
• UltraSPARC 64 fully supported
• AMD x86-64 [x86-64.org] support
• SSE/SSE2/3DNow!/MMX instructions and command-line flags to enable. No C++ compatible intrics for SSE2
• New ports for MMIX [stanford.edu], CRIS, and SuperH [superh.com]
• Code profiling

Everyone knows I'm no fan of the GNU project, but GCC3.1 shows that they have a lot going for them. Very exciting guys, I can't wait to see what 3.2 has in store.

--Dan

Re:Most Notable Improvements - export?

[jungd]

Does it implement export yet?
I doubt it.

Re:Most Notable Improvements - export?

[jdennett]

Nope, the only compilers which are close to having export are the EDG-based ones. Comeau might be on sale in release (rather than beta) form this month. No released compiler has export just yet, but some are real close now. (http://www.edg.com/ or http://www.comeaucomputing.com/ for some more details if you care.)

Re:Most Notable Improvements - export?

[iguana]

Forgive my ignorance, but what is export?

Re:Most Notable Improvements - export?

[Anonymous Coward]

In short: thing that reduces bloat/speed/compile time when you use templates. Every bigger c++ (KDE and the like) project would kill for it. But AFAIK it is difficult to implement... pitty.

Re:Most Notable Improvements - export?

[jdennett]

export is unlikely to help to reduce bloat. Coding well or using a smart compiler will do that. Compile time doesn't appear to much be affected by initial implementations of export.

Export helps to reduce header file dependencies, which is a good thing. It also makes it possible to ship template libraries without exposing implementation details as plain text.

Re:Most Notable Improvements

[argel]

UltraSPARC 64 fully supported
I can't wait to see what 3.2 has in store.

Probably stable UltraSPARC 64 support! ;-)

Re:Most Notable Improvements- Ada 95

[Ada95]

Those are all important improvements but surely the most important change is the inclusion of the GNU Ada 95 compiler (GNAT) in the GNU Compiler Collection. Try it! Be cool. Be leading edge. Be smart. Be productive.

When..

[hackwrench]

will it be available in Cygwin...

Re:When..

[Anonymous Coward]

Try bulding it from sources.

Anybody tried it yet?

[qeL3-i]

Has anybody tried using it yet? I don't want to be the first kid on the block to give it a go...

Trouble

[4of12]

[Well, I won't dwell on my rejected submission for this.]

But my attempt to build gcc 3.1 on sparc-sun-solaris2.8 gave me this problem:

echo timestamp > s-check
stage1/xgcc -Bstage1/
-B/usr/local/sparc-sun-solaris2.8/bin/ -c
-DIN_GCC -g -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic
-Wno-long-long -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I. -I../../gcc-3.1/gcc
-I../../gcc-3.1/gcc/. -I../../gcc-3.1/gcc/config
-I../../gcc-3.1/gcc/../include ../../gcc-3.1/gcc/p rint-rtl.c -o print-rtl.o
In file included from
../../gcc-3.1/gcc/print-rtl.c:30:
../../gcc-3.1/gcc/tree.h:3183: stray '\273' in program
../../gcc-3.1/gcc/tree.h:3183: stray '\224' in program
../../gcc-3.1/gcc/tree.h:3183: stray '\315' in program
../../gcc-3.1/gcc/tree.h:3183: stray '\352' in program
../../gcc-3.1/gcc/tree.h:3183: stray '\274' in program
../../gcc-3.1/gcc/tree.h:3183: parse error before '&' token
../../gcc-3.1/gcc/tree.h:3183: stray '\246' in program
../../gcc-3.1/gcc/tree.h:3183: stray '\21' in program
.
.
.
[This went on for some while.]

Any ideas?

Re:Trouble

[morbid]

Are you running on x86 or SPARC?
I've built various versions of gcc-3.0.x and 3.1-xxxxx on SPARC and intel multiprocessor boxen on Solaris 8 and 9.
What C compiler are you using to start the bootstrap build?

I have the Freeware Companion CD installed, so am using gcc-2.95.3.

Here is my configure line:

../gcc-3.1/configure --prefix=/area51/trial/install/gcc-3.1 --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as --without-gnu-ld --without-gnu-as --enable-shared

Re:Trouble

[4of12]

This is SPARC (v9).

Solaris 8.

My first attempt failed, using gcc 3.0.4 to do the bootstrap build.

My second attempt failed, using Suns WS 6u2.

Thanks for the configure line. I'll also try extracting on a different filesystem as another poster suggested, since the symptoms look suspicious.

Does it compile KDE?

[JahToasted]

How is the C++ support now? I've been sticking with 2.95.x since 3.0 wasn't able to compile kde (i think it was the sound system it couldn't compile although I could be wrong). There was nothing wrong with the KDE code it was a problem with gcc3. So any word on whether c++ has been fixed? does the linker work properly or do we still have to use objprelink?

I remember being optimistic about 3.0 only to be disapointed that it wouldn't compile kde.

Re:Does it compile KDE?

[Anonymous Coward]

Yes, some of the KDE developers are already using GCC 3.1. It compiles and runs KDE without problems.

Sigh

[devphil]

Yes, GCC 3.1 compiles KDE 3.0 just fine, according to initial prerelease reports. However...

So any word on whether c++ has been fixed?

"C++" as you call it, was doing pretty well. Most of the problem was that the KDE library folks expected to be able to break the ODR and have GNU ld magically fix it for them. (Even open source projects have to follow the rules of the programming language in use, sorry...)

Re:Sigh

[devphil]

ODR is One Definition Rule. It's the clause of the ISO C++ Standard (that's where you'd go to look for it) that says that an entity used in a program must be defined exactly once.

Some of the KDE libs apparently were trying to define things more than once, and have the linker merge them. Which falls outside the realm of C++, and is actually done for some behind-the-scenes things, but not normally, and not by default.

Anyhow, there was a long thread on the gcc list, where the remaining multiple inheritence issues were dealt with, and the ODR problems explained to the good KDE folks. So all should be well there.

Slow startup times remain; that's a different problem.

Re:Sigh

[devphil]

Well, yeah, but it only works when you tell the compiler and linker what you're doing. The '#pragma telepathy' extension still hasn't been checked in to the main GCC source tree. :-)

Under Solaris, I do similar things with the uber-kickass watchmalloc library.

Re:Does it compile KDE?

[tzanger]

How is the C++ support now? I've been sticking with 2.95.x since 3.0 wasn't able to compile kde (i think it was the sound system it couldn't compile although I could be wrong).

I think you're very wrong -- I have compiled KDE3 from CVS with GCC3.0 many times without a problem.

I Hope....

[pretoris]

I hope Apple has the insight to ship this version of GCC with Jaguar rather than the much maligned GCC 3.0.x

Re:I Hope....

[jdennett]

If you really want a solid gcc, 3.0.4 is probably your best bet right now. The 3.0.x line has had by far the most testing of any recent version. 3.1 seems pretty good, but many regressions have been fixed "at the last minute" and there are still some known and some unknown regressions. If you want the improved conformance and better optimizers etc. then 3.1 is a good bet. If it's just stable you're looking for, then 3.0.4 is sane, or maybe 3.1.x fairly soon.

Prelinking?

[Anonymous Coward]

Is now prelinking possible (with current/next binutils/glibc)? Real prelinking, not objprelink or combreloc.

GCC and Linux Kernel

[g_dancer]

Does GCC 3.1 build the Linux kernel correctly now? I had problem with the GCC 3.0.x versions and some 2.4 kernel modules.

Re:GCC and Linux Kernel

[tzanger]

Does GCC 3.1 build the Linux kernel correctly now? I had problem with the GCC 3.0.x versions and some 2.4 kernel modules.

Which modules? I've been compiling 2.4.18 with ipsec and the bleeding edge ACPI stuff for quite a while now. Nothing weird yet...

8-bit register use on x86 ?

[Anonymous Coward]

Can code generated by this version of GCC use, say, registers AH and AL at the same time? I don't think GCC 2.x can do this.