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

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

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?

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