GCC 3.3 Released

devphil writes "The latest version of everyone's favorite compiler, GCC 3.3, was released today. New features, bugfixes, and whatnot, are all available off the linked-to page. (Mirrors already have the tarballs.) Let the second-guessing begin!"

gcc 3.3 fails on glibc 2.3.2

[Anonymous Coward]

just for information re-compiling glibc 2.3.2 with gcc 3.3 fails. i don't see the point releasing a compiler or standard glibc which doesn't allow the existing compiler to be used to compile it.

GCC 3.3

[Anonymous Coward]

Congratulations, so many bugs fixed, cool!
I wonder ow much slower than the last release is it...

Sigh

[unixmaster]

And "cant compile kernel with gcc 3.3" messages started to appear on lkml. Is it me or gcc team goes for quantity rather than quality that they even postponed many bugs ( like c++ compile time regression ) to gcc 3.4 to release 3.3...

Bounds Checking

[the-dude-man]

I hear they have added in some more advanced, and aggressive bounds checking. Now when i screw up something i wont have to wait for a seg-v to tell me that pointer moved a little too far.

Although it dosnt seem to work with glibc....this is quite annyoing, although it probably will be fixed and re-released in a few days

ABI?

[42forty-two42]

Does this release break binary compatibility?

slower than the last release....

[oliverthered]

The optimiser has been vastly improved and ....

The following changes have been made to the IA-32/x86-64 port:
SSE2 and 3dNOW! intrinsics are now supported.
Support for thread local storage has been added to the IA-32 and x86-64 ports.
The x86-64 port has been significantly improved.

If you wan't compile time performance look at

Precompiled Headers [gnu.org]

Two things I don't understand.

[torpor]

I don't understand these two points, maybe someone can explian:

The preprocessor no longer accepts multi-line string literals.

Why was this removed?

And:

The header, used for writing variadic functions in traditional C, still exists but will produce an error message if used.

This I don't understand at all. Does it mean we can't write void somefunc(int argc, ...) style funcs any more?

Someone, please explain...

SuSE already uses it

[red_dragon]

I just got SuSE 8.2 installed this week, which includes GCC 3.3, and noticed that the kernel is also compiled with GCC 3.3. From 'dmesg':

Linux version 2.4.20-4GB ([e-mail]) (gcc version 3.3 20030226 (prerelease) (SuSE Linux)) #1 Wed Apr 16 14:50:03 UTC 2003

Precompiled header support

[Anonymous Coward]

I have been wondering about this for more than half a decade now:

Why is it that GCC never seem to get precompiled header support added?

The compilation speed of GCC is one of its biggest weaknesses when you compare it to eg MSVC. All Windows compilers seem to have had this since the DOS days, but still GCC have never gotten this feature. How come?

Re:this is all well and good

[double_u_b]

Visual Studio (v6) is a really bad IDE. I prefer Borland C++ Builder from far. And Visual C++ is really abject on some aspects: why does it compiles things differently if you are in debug mode? I used VC++ to code a file compression utility. Operator precedence is not the same between debug and release compiler mode. Debug had the same behaviour than GCC, Watcom or Borland. Release mode had a different behaviour. Not nice, since it took me hours to find wherethe bug was, since you can't easily debug a release executable... Moreover, speed-optimisation nearly always produces bad code. And debugging 'const' functions in C++ make the debugger go wild. Borland had neither of those problems. And the code looked cleaner when showed by BC++ Builder. Nevertheless, what I really like is the EclipseIDE, and the IDE of BeOS.

What does it mean?

[commanderfoxtrot]

That's great... but can anyone tell us what a difference all that will make? I don't really care about compile times (too much)... but will mpeg2enc or ffmpeg run faster?

BTW, there is a preliminary ebuild in Gentoo.

Re:gcc 3.3 fails on glibc 2.3.2

[Anonymous Coward]

don't you think that a compiler should at least be able to deal with the last release of a core system component such as glibc ?

The compiler should at least be able to compile a) the Kernel b) the Glibc.

From the release timeframe a) is no problem. But b) usually takes half - one year to show up with a new release. They should at least release gcc and glibc at the same time or at least provide patches. Regardless to that the glibc and gcc people are almost the same persons so they should know best.

Re:Precompiled header support

[Dionysus]

Is precompiled header support even necessary?
If you follow the advice of any good programming book, you shouldn't be including unnecessary header files anyway.

One of the reason you need precompiled header support in Windows, is because to write any meaningful Windows program, you need to include <windows.h>, which include everything.

Re:gcc 3.3 fails on glibc 2.3.2

[rmathew]

*Why* do you say that? I mean, can you point to some page that details the problems

Re:Everyone loves GCC?

[turgid]

Kylix is all well and good if you only need to compile code for the i386 architecture. If you need UltraSPARC, MIPS, PowerPC, M68k etc. you're up the creek. If you want a nice Free IDE you could try anjuta [sf.net]. It needs the GNOME libs though.

Intel C++ Compiler 7.1 Rules

[Anonymous Coward]

Intel's compiler [intel.com] smokes gcc in most benchmarks (not surprising, given that Intel knows how to squeeze every last bit of performance out of their own processors). Although it is not 100% compatible with all the gcc features, and therefore can't compile the Linux kernel, each release adds more and more compatibility. I hope the day will soon come when we can compile a whole Linux distribution with the Intel compiler.

Re:this is all well and good

[pommiekiwifruit]

Operator precedence is not the same between debug and release compiler mode.

Are you sure you are not getting precedance confused with order of evaluation between sequence points?

C++ has fairly flexible rules in that regard, the much discussed (on comp.lang.c++) undefined behavior and implementation-dependant behaviour. For example i=i++; invokes undefined behaviour that may vary between compiler settings. My instinct would be that that is more likely to be the problem than compiler error in most cases. You should post the problem code to see if that is the case.

Re:Yes but...

[Anonymous Coward]

Agreed. But I see two paths to optimization (probably more--I'm not a compiler writer). First, there are optimizations that work well on all processors. Things like inline function calls, loop unrolling, etc. Second, there are optimizations that work on a per processor basis. For example, using instructions in such a way that the processor's pipelines are filled and that its branch prediction doesn't choke, etc. Clearly Intel has the advantage in making the second type of optimizations. But do you think they also have the advantage in the first type as well? The only way to find out would be for Intel to work on gcc's intel-compling mode. Then benchmarks would show which does the better job of doing optimizations of the first type.

I think the argument can be made

[smittyoneeach]

in response to

Windows - developer friendly. Linux - developer hostile.

that open source requires more skill on the part of the developer to get through the learning curve.
A greater amount of knowledge about what is happening at all levels is mandatory to make that GNU\Linux system happen.
Whether this is a but or feature probably depends on your current location on the learning curve. The more I interact with open source, the more I like the fact that there are relatively fewer secrets about what is occuring, a feature that seems lost by the time you reach the West Coast...

A bug in a deprecated GCC extension

[Per Abrahamsen]

Treating casts as lvalues is a GCC extension, and an extension that has been deprecated for C++ since 3.0 because it causes problems for valid C++ code.

I believe the plan is to add a warning in 3.4 and remove it in 3.5.

Re:Sigh

[Anonymous Coward]

Aren't hand-coded recursive descent parsers generally slower than machine-generated ones? Isn't that the point of YACC?

Re:Sigh

[uncleFester]

In the past, when a kernel has not compiled with a new gcc version it has been more often a bug in the kernel than one with gcc..

not really; it's a combination of kernel developers trying things to deal with 'intelligent' inlining, or implementing hacks when they discover an idiosyncrasy with GCC. As the gcc team 'resolves' (fixes? ;) such things the hacks may then fail, resulting in compile errors. unfortunately, this can make the code MORE fun as you then have to add compiler version tests to check which code should be used.

The goal, though, is using the latest kernel with the latest compiler will generate the most correct code. Simply pointing a finger at the kernel developers is incorrect; both sides can be the cause of compiler failures.

disclaimer: not a kernel developer, just a more-than-casual observer.

'fester

Re:this is all well and good

[jmccay]

Actually, Visual Studio is a great IDE. It's one of the few things Microsoft did well. It's not easy to understand at first, but it you take the time to learn it, you'll appreciate it.
My favorite feature was the scripting ability. You could write VB Scripts (or start by recording them as a macro) to accomplish tasks. I wrote several VB Scripts that wrote out comments in the code.
KDevelop is the only thing I have seen that's close to Visual Studio. I have C++ Builder 3.0 Professional at home, but I still like the design and easy of use of Visual Studio. The C++ Builder interface is missing some things--like scripting.

Re:Bounds Checking

[swillden]

I hear they have added in some more advanced, and aggressive bounds checking.

What are the run-time performance implications of this bounds checking? It sounds very nice for debugging, and a great thing to turn on even in production code that may be vulnerable to buffer overflow attacks, but it can't be free. A bit of Googling didn't turn up anything; does anyone know how expensive this is?

So when do we get a working debugger for g++?

[Anonymous Coward]

It's great to hear about all these new improvements in gcc, but what I really want is a working debugger for C++ code compiled with gcc. The gdb debugger is buggy as all hell. It gives wrong values for variables, has no end of troubles with C++, and often enough when I want to print out the value of a variable it tells me that it can't access that memory, with no further explanation.

Re:What does it mean?

[commanderfoxtrot]

In the short run, nothing changes. In the long run, programs become better as they stick to better programming guidelines

Not very promising!! Basically you're saying this won't make much difference to the end user in terms of speed. I'm not arguing -- I'm agreeing.

Personally, I would much rather have a slow compiler which gets the most out of my system. Apparently the gcc2.95-age compilers are faster than the gcc3 series: in my book that's a good thing. But has anyone done any testing? How long does it take to do something CPU intensive with each compiler version? It wouldn't take much skill to make a script encoding an SVCD using mencoder/transcode compiled with different gcc versions -- any takers? (I'm in my master's exams...)

And when will there be proper support for my Morgan Duron? At the moment I use athlon-xp in order to use my SSE instructions: but surely the cache size makes a difference to the code gcc should put out?

Still buggy for Dreamcast

[Forkenhoppen]

It's a shame that no one managed to fix bug #10392 [gnu.org] before release. Until that one's fixed, those of us who do Dreamcast hacking are stuck using GCC 3.0.4.

Re:What does it mean?

[Anonymous Coward]

AFAIK there are no automatic cache optimizations that would be relevant in a relatively low-tech compiler such as GCC. There are some commercial bleeding-edge compilers that can do cache blocking in some circumstances, but languages such as C and C++ make such optimizations fiendishly complicated. Also, I've never seen cache sizes mentioned as an issue with regards to GCC optimizations, and I've been using GCC and following its development for close to a decade now.

Re:nonnull function attribute

[GlassHeart]

Seems useful, though I suspect many derefernced pointers are set NULL at runtime, and so not spottable during build.

It's possible to check at compile time. It's not so much that the compiler detects whether a parameter is null or not at compile time, but whether it can be. For example:

extern void do_work(void *) __attribute__ ((nonnull));
void *p = malloc(100);
do_work(p);

can trigger a warning or error, because malloc() does not return a "nonnull" pointer, and so passing p to do_work is dangerous. On the other hand, given the code:

extern void do_work(void *) __attribute__ ((nonnull));
void *p = malloc(100);
if (p != NULL) {
do_work(p);
}

then the compiler can work out that the call is safe. This is how LCLint, for example, can do with its /*@null@*/ attribute. The logic will be a little like tracing whether a const variable is passed to a function expecting a non-const parameter. I don't know how far gcc plans to take this feature.

Re:Two things I don't understand.

[jmv]

About the multi-line strings, I think there's one place where I think they were really useful: inline assembly. I've got source files with big chunks (> 100 lines) of assembly and it's a pain to have a ".... \n" on each line.

Re:Hmph

[devphil]

Now I understand what Bjarne Stroustrup wrote, when he described /. as "ignorant, and proud of it." Indeed, let the second-guessing begin...

especially for C++, as it's standard keeps "refining" constantly,

The standard hasn't changed since 1998.

as does GCC's interpretation of it. Not to mention the extensions.

The extensions are, in many cases, older than the standard. Now they conflict with rules added by the standard. One or the other has to give. And, of course, no matter what happens, somebody out there will declare that GCC "obviously" made the wrong choice.

If you think it's easy, why don't you give it a try? Hundreds of GCC developers await your contributions on the gcc-patches mailing list.

If you don't like it, you should demand your money back.

Right now I'm [making changes]. What next?

Again, the standard was published in 1998. The three changes you describe were decided upon even before then, and they haven't changed since. You've had 5 years to walk down to the corner bookstore and buy a decent book, or search on the web for "changes to C++ since its standardization". None of those changes are due to GCC, and trying to shift the blame to GCC only points out your employer's laziness.

You've had half a decade. Catch the hell up.

Re:Mostly compatible, but...

[Micah]

Is there any reason NOT to declare i386 support dead? No one is going to compile newer software for a 386 (bloat, etc) and older compilers work fine for older software.

Re:A question about gcc cpu Optimization?

[dhazeghi]

Well, remember the kernel is to a large extent already optimized. So most generic optimizations won't help a whole lot. Still you can always try. Plus it's a great way to shake out hidden bugs in either gcc or the kernel...

Re:gcc 3.3 fails on glibc 2.3.2

[nusuth]

glibc is part of GNU project and gcc compiled stuff is expected to link with it more often than not, so I concur about compatibility. I think glibc people be warned and should be fixed before release of gcc though.

As for the kernel, which "the" kernel is that?