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

Comments

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?

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

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

[mickwd]

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

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 support
• SSE/SSE2/3DNow!/MMX instructions and command-line flags to enable. No C++ compatible intrics for SSE2
• New ports for MMIX, CRIS, and SuperH
• 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

[argel]

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

Probably stable UltraSPARC 64 support! ;-)

When..

[hackwrench]

will it be available in Cygwin...

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

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

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.

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

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