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

Comments

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.

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

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

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

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?

ABI?

[42forty-two42]

Does this release break binary compatibility?

Intel C++ Compiler 7.1 Rules

[Anonymous Coward]

Intel's compiler 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.

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

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.

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