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

Re:Sigh

[norwoodites]

Correctness is more important than compile time that is why it is being pushed back, most of the compile time regressions have to do with the inliner and its limits.

Re:gcc 3.3 fails on glibc 2.3.2

[bconway]

I don't see the point in making changes to a compiler that shouldn't be made solely to satisfy a single piece of software. If the problem is with glibc, it should be fixed, not worked around. What if XFree86 failed to compile, should GCC work around that? How about Mozilla or OpenOffice.org?

Re:SuSE already uses it

[red_dragon]

Yes, it does say 'prerelease', which I didn't miss (I did type that dmesg string in, y'know). The date isn't too far in the past, though, so differences between that and the release version shouldn't be that great.

Re:this is all well and good

[TrancePhreak]

Sounds like you just don't have a lot of experience compiling. The first thing you do when something acts out of spec is to clean and then rebuild. This probably would have solved a lot of your troubles. The GNU make has this bug even worse, since it only checks file size most of the time. Speed optimization has _never_ in my 5 years of using VC++ produced bad code. Please stop with the trolling and get back to learning how to use the compilers properly.
Borland C++ was okay 6 years ago, but after VC6 came out it's easy to see why it's not so great any more. Two more IDE updates and the old BC is left far behind. I'd take many OpenSource IDE's over BC. Features such as auto-completion and code collapsing have saved me a good deal of time & typing.

Re:Two things I don't understand.

[swillden]

You can write that code but not:

char *A="A
B";

Not to mention the fact that it's unclear exactly what A contains. I can see that it begins with "A" and ends with "B", but what's in between? Some amount of whitespace, clearly, including a newline, but there could be an arbitrary number of tabs and spaces in there as well.

char *A="A\nB";

is much better code.

From the changes

[pheared]

The C and Objective-C compilers no longer accept the "Naming Types" extension (typedef foo = bar); it was already unavailable in C++. Code which uses it will need to be changed to use the "typeof" extension instead: typedef typeof(bar) foo. (We have removed this extension without a period of deprecation because it has caused the compiler to crash since version 3.0 and no one noticed until very recently. Thus we conclude it is not in widespread use.)


Or rather, gcc version >= 3.0 is not in widespread use.

Check out Eclipse

[Anonymous Coward]

I agree that Visual Studio is a pretty decent IDE. I've used it for years and have grown to love it.

However, after using Eclipse, I'm never going back (except if I need a good Win32 GUI resource editor).

Re:this is all well and good

[jonadab]

> Windows - developer friendly. Linux - developer hostile.

Is that why Windows has 95% of the users and 60% of the developers,
while Linux/BSD/Unix (excluding Mac) have 1% of the users and 85%
of the developers? Yeah, Linux is *real* developer-hostile. The
way it hides all the implementation details makes it so hard for
programmers to get things working...

Calling Linux user-hostile would be a gross exaggeration, but at
least it would be barking up something that resembles a tree.

Re:Intel C++ Compiler 7.1 Rules

[BreadMan]

no software is good enough to pay for

You don't pay for software as much as you pay people for making software. I don't work for free and I'm betting you don't either.

The gcc compiler/toolset is great. You can tell the engineers put thier heart in the work, to paraphrase a robber baron. Putting few bucks into thier pockets to reward them for thier hard work and excellent product is A Good Thing. Recognition is great compensation if your other material needs/wants are met.

Check out the FSF shopping [fsf.org] page. The books are great and well worth the money. The art work [gnu.org] isn't quite my thing. Does your employer match United Way contributions? Direct [gnu.org] some of your giving to the FSF.

Ridiculous

[Anonymous Coward]

Okay, while libc and gcc are technically different projects, as I understand it, I agree that it would seem reasonable to drop a note to the libc folks saying "hey, gcc can't compile libc" and waiting for an update before releasing.

On the other hand, the argument that the gcc folks should make sure that the *kernel* (presumably the Linux kernel) compiles is absolutely ridiculous. The kernel has been long broken and not language-compliant. I think recent compilers can compile it, but that's very recent, and hardly the fault of the gcc people. The Linux kernel has no association with gcc, and is not an amazingly clean project. Gcc is used in far more places than Linux is -- on just about every OS and architecture in the world. Blocking a gcc release because the Linux kernel doesn't compile would be insane. Gcc is *far* bigger than Linux. It is the standard available-everywhere compiler.

When someone misuses English, do you correct them or change the entire language to fit their mistake?

I'm still amazed

[drxenos]

I have always been amazed that such an impressive compiler is still free. Thanks to the GCC team. You guys/gals rock!

Re:inline

[Shimmer]

I don't understand this. Inlining is an optimization -- it has no semantic effect. How could failure to inline cause something to break?

-- Brian

Re:Hmph

[avdi]

Sounds like you've been coding to a very old pre-standard version of C++ for a long time. Don't complain that the standard keeps "refining" - what you are talking about are things that have been stable for years. Count yourself lucky that compilers actually let you get away with it all this time.

And I hope you aren't putting "using namespace std" in new code. Ugh.

Re:Mostly compatible, but...

[volkerdi]

The thing is, if you have to configure gcc-3.3 for and i486 target in order to be binary compatible with gcc-3.2.x comfigured for i386, then gcc support for i386 might as well be dead, because all the OS distributions will be compiling it for i486 (or better). I doubt we'll see too many gcc or glibc packages for i386 after that.

We've fixed that for 3.4, and for 3.3 to some

[devphil]

"...to some extent." Why give a Subject: line textbox that won't let me use all of it? Grrr.

Anyhow. One of the big speed hits for iostream code was the formatting routines. Some other reply has a subject like "if you're using fstream you're not interested in performance anyhow," which is so wrongheaded I won't even bother to read it. There's no reason why iostreams code shouldn't be faster than the equivalent stdio code: the choice of formatting operations is done at compile-time for iostreams, but stdio has to parse the little "%-whatever" formatting specs at runtime.

However, many iostreams libraries are implemented as small layers on top of stdio for portability and compatability, which means that particular implementation will always be slower.

We were doing something similar until recently. Not a complete layer on top of stdio, but some of the formatting routines were being used for correctness' sake. We all knew it sucked, but none of the 6 maintainers had time to do anything about it, and the rest of the world (that includes y'all, /.) was content to bitch about it rather than submit patches. Finally, Jerry Quinn started a series of rewrites and replacements of that section of code, aimed at bringing performance back to 2.x levels. One of the newer maintainers, Paolo Carlini, has been working unceasingly at iostream and string performance since.

So, all of that will be in 3.4. Chunks of it are also in 3.3, but not all. (I don't recall exactly how much.)

Re:Precompiled header support

[GlassHeart]

Is precompiled header support even necessary?

It's not necessary, in the sense that you'll still get correct code without it.

If you follow the advice of any good programming book, you shouldn't be including unnecessary header files anyway.

I don't. Precompiled headers just means that I get my executable more quickly. Some headers are bigger than your usual C or C++ files!

Re:I think the argument can be made

[Junks Jerzey]

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.

No offense, but that's just so much self-justification. Personally, I'm growing tired of that kind of faux elitist stance.

Re:Intel C++ Compiler 7.1 Rules

[RealAlaskan]

Intel's compiler smokes gcc in most benchmarks ...

How's its performance on SPARC III? Does it optimize well for the Athlons? How about the PowerPC CPUs? And the MIPS CPUs? Does it cross-compile for the IBM mainframes? Does it run on them?

Although it is not 100% compatible with all the gcc features, and therefore can't compile the Linux kernel, ...

Oh.

How about the object code? Can its object code be linked to code compiled by gcc, or is using this an all-or-nothing proposition?

I hope the day will soon come when we can compile a whole Linux distribution with the Intel compiler.

That would be nifty, indeed. At least it would be nifty for the distributions which run ONLY on Intel CPUs. Which distribution would that be?

Intel's compiler is certainly peachy, and I would certainly endorse its use by folks who have Intel systems and need to get maximum performance out of them. Same story for the Digital/HPAQ compiler and the folks with the Alpha systems.

For the rest of us, the folks without Intel CPUs, Intel's peachy compiler is not so much of a muchness. But don't let that stop you from going crazy with it.

Re:Compile-time performance

[HuguesT]

That's all very nice to say that 3.x is slower to compile than 2.95.s, but the end result, the executable, is faster (by ~10% on SPEC benchmarks), and 3.x releases are a lot closer to the ISO standards (both C and C++) than 2.95.x, so I don't see why we should all weep.