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

woo!

[KrON]

mmm i'll install this one only cuz it rhymes ;)

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.

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

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?

Re:Ridiculous

[TheRaven64]

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.

libc and glibc are not quite the same, however. libc refers to any implementation of the standard c library, while glibc is the GNU version. I use gcc with the MSVCRT, the cygwin libc and the FreeBSD libc. To me glibc is just another piece of software that people who are not

Re:gcc 3.3 fails on glibc 2.3.2

[jmv]

Typically, all gcc releases break the kernel somewhere. This is because many kernel rely (unintentionally) on some behaviour of gcc that is not guaranteed by the standard. When a new gcc release comes, they need to make sure they fix that. That's why there's always a "list of supported compilers for the kernel". There's no reason why the gcc folks should refrain from using some optimizations because it would break bad code in the kernel.

Re:gcc 3.3 fails on glibc 2.3.2

[jmv]

It's not necessarily someone who doesn't know the language. Sometimes "normal" mistakes happen and don't get corrected because nobody noticed (i.e. because the compiler generated code that didn't expose the bug). Alan Cox once said that if you don't have access to a big endian machine, there's no way your code will work perfectly on such machine (though you can come close, you'll always miss one). The same is true with compilers: unless you have a compiler that generated bad code for 100% of the cases where you're not following the language perfectly, you won't catch all bugs.

Most of the times, this is not obvious stuff. A while ago, gcc 2.95 (or was it 2.96?) broke the kernel because of the strict aliasing rules: gcc assumes that an (int*) and a (float*) can't point to the same area (even now, the kernel needs to be compiled with -fno-strict-aliasing). One of the reasons why gcc 3.3 breaks the kernel now is that at some places, the kernel assumes that an inline function will be inlined, otherwise it breaks. The older versions of gcc always made those functions inline, but the new version take inline merely as a hint (like "register"), which is compliant with the standard. The kernel needs to be fixed to say "inline this or die" or something like that instead.

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:gcc 3.3 fails on glibc 2.3.2

[norwoodites]

Try this link instead: http://gcc.gnu.org/PR8610 [gnu.org], it is smaller and easier to remember.

SERVAR == TEH VARY SLWO

[Anonymous Coward]

Caveats
The preprocessor no longer accepts multi-line string literals. They were deprecated in 3.0, 3.1, and 3.2.
The preprocessor no longer supports the -A- switch when appearing alone. -A- followed by an assertion is still supported.
Support for all the systems obsoleted in GCC 3.1 has been removed from GCC 3.3. See below for a list of systems which are obsoleted in this release.
Checking for null format arguments has been decoupled from the rest of the format checking mechanism. Programs which use the format attribute may regain this functionality by using the new nonnull function attribute. Note that all functions for which GCC has a built-in format attribute, an appropriate built-in nonnull attribute is also applied.
The DWARF (version 1) debugging format has been deprecated and will be removed in a future version of GCC. Version 2 of the DWARF debugging format will continue to be supported for the foreseeable future.
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.)
The -traditional C compiler option has been removed. It was deprecated in 3.1 and 3.2. (Traditional preprocessing remains available.) The header, used for writing variadic functions in traditional C, still exists but will produce an error message if used.
General Optimizer Improvements
A new scheme for accurately describing processor pipelines, the DFA scheduler, has been added.
Pavel Nejedly, Charles University Prague, has contributed new file format used by the edge coverage profiler (-fprofile-arcs).

The new format is robust and diagnoses common mistakes where profiles from different versions (or compilations) of the program are combined resulting in nonsensical profiles and slow code to produced with profile feedback. Additionally this format allows extra data to be gathered. Currently, overall statistics are produced helping optimizers to identify hot spots of a program globally replacing the old intra-procedural scheme and resulting in better code. Note that the gcov tool from older GCC versions will not be able to parse the profiles generated by GCC 3.3 and vice versa.

Jan Hubicka, SuSE Labs, has contributed a new superblock formation pass enabled using -ftracer. This pass simplifies the control flow of functions allowing other optimizations to do better job.

He also contributed the function reordering pass (-freorder-functions) to optimize function placement using profile feedback.

New Languages and Language specific improvements
C/ObjC/C++
The preprocessor now accepts directives within macro arguments. It processes them just as if they had not been within macro arguments.
The separate ISO and traditional preprocessors have been completely removed. The front-end handles either type of preprocessed output if necessary.
In C99 mode preprocessor arithmetic is done in the precision of the target's intmax_t, as required by that standard.
The preprocessor can now copy comments inside macros to the output file when the macro is expanded. This feature, enabled using the -CC option, is intended for use by applications which place metadata or directives inside comments, such as lint.
The method of constructing the list of directories to be searched for header files has been revised. If a directory named by a -I option is a standard system include directory, the option is ignored to ensure that the default search order for system directories and the special treatment of system header files are not defeated.
A few more ISO C99 features now work correctly.
A new function attribute, nonnull, has been added which allows pointer arguments to functions to be specified as requiring

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:What does it mean?

[noda132]

Not many visible changes. Developers have better profiling, which means eventually if they care they can make software faster. Also, you're going to find a lot more compiler warnings, and perhaps the odd piece of software which doesn't compile at all. In the short run, nothing changes. In the long run, programs become better as they stick to better programming guidelines (since gcc doesn't support "bad" programming as well as the previous version).

I've been using gcc 3.3 for months from CVS, and have had no problems with it (except for compiling with -Werror).

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

Re:SERVAR == TEH VARY SLWO

[jmccay]

>Also, some individual systems have been obsoleted: ...
>Intel 386 family
>Windows NT 3.x, i?86-*-win32

Does this mean that they are not going to support win32 any more. I still use mingw (Windows Port of gcc) as my primary compiler because it's free, and I don't have money to replace my PII 350 Windows 98 system.

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.

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

Sigh, indeed...

[squarooticus]

You DO realize that most of the problems compiling the Linux kernel with succeeding releases of gcc is due primarily to the kernel team making incorrect assumptions about the kernel output...

Right?

Re:Sigh

[Ed Avis]

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. The same goes for most apps. Looking at the list archives, the main problem seems to be with __inline__ which was a gcc extension to start with, so the problem is presumably that the meaning of that keyword has been deliverately changed.

inline

[Per Abrahamsen]

The inline flag in C and C++ is a hint to the compiler that inlining this function is a good idea, just like register is a hint to the compiler.

GCC has always treated inline as such a hint, but the heuristics of how to use the hint has changed, so some functions that used to be inlined no longer is inlined.

The kernel has some function that *must* be inlined, not for speed but for correctness. GCC provide a difference way to specify this, a "inline this function or die" flag. Development kernels use this flag.

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

[WNight]

That relies on the assumption that you can always page in the memory containing the subroutine. If you're writing paging code this might not be possible.

It was a lot harder in real-mode programming, where you couldn't jump to distant code because you had to change segment registers and you had to make sure you backed them up first. Hard to guarantee with C, easy with ASM.

Besides, there are many optimizations that a compiler has to guess about. It's very hard for it to know if you're relying on the side effects of an operation. If you're looping and not doing anything, are you touching volatile memory each time (where the reads could be controlling memory-mapped hardware) or doing something else similar. That's the most obvious example. There are a ton of pages about compiler optimization. It's really quite fascinating.

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

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

[norwoodites]

Linux, the kernel, depends on old gcc extensions that are slowly being removed from gcc, extensions that were not documented. Also c++ compile time is a hard thing to fix if you want a full c++ compiler in a short period of time. 3.3 is very stable compiler, even 3.4 in the cvs is a stable compiler. The gcc team are all volunteers so why do you not help them and fix some problems, and/or report some problems to us (I am slowing helping out now).

Re:Sigh

[Horny Smurf]

gcc 3.4 is slated to include a hand-written (as oppsed to yacc-built) recursive descent parser (for c++ only). That should give a nice speed bump (and fixes over 100 bugs, too).

The hand written parser

[Per Abrahamsen]

Does amazing thing for correctness, and is much easier to understand. However, it is not faster in general. It is faster at some tasks and slower at others, same on average.

It also exposes tons of errors in existing C++ programs, so expect lots of whining when GCC 3.4 is released.

GCC 3.4 will have precompiled headers (thanks Apple), which will speed compilation up a lot for project that uses them.

I don't have a life

[Per Abrahamsen]

thus, I can follow the development list.

PCH vs. compile server

[Per Abrahamsen]

The compile server was still experimental last I heard.

You need to reorganize your Make files to use pch's efficiently. You should

1) Not change any of your source or header files.

2) Add a new "all.h" header including all other headers, and precompile that header and only that header, whenever any other header changes.

3) all.h should not be included directly from any file, instead compile with a special flag that "pre-includes" all.h.

4) Because of header guards (which you must use), none of the normal

Re:Sigh

[Per Abrahamsen]

Yacc and similar tools are optimized for languages with "nice" grammars, and have hacks to support languages with less nice grammars. The number of hacks needed to support C++ is so large that it evidently slow down the whole parser, not to mention make it unreadable. At that point, writting an add-hoc parser is better.

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

[asuffield]

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.

Indeed, that SIGSEGV becomes a SIGABRT instead. This is dynamic bounds checking; it won't find anything until the bounds error occurs at runtime, so you won't find it any earlier. All it does is make sure that no bounds errors escape *without* crashing the process.

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

I guess you didn't read the documentation. This is a "feature". It breaks the C ABI, forcing you to recompile all libraries used in the program, including glibc.

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?

Be careful

[swagr]

I'm waiting for SCO to show it's copied code before I pick up any GNU software.

ABI?

[42forty-two42]

Does this release break binary compatibility?

Mostly compatible, but...

[r6144]

According to this [gnu.org], if your program is multi-threaded, uses spinlocks in libstdc++, and runs on x86, then you'll have to configure gcc-3.3 for a i486+ target (instead of i386) in order to make it binary compatible with gcc-3.2.x configured for a i386 target. Otherwise when the code is mixed, the bus isn't locked when accessing the spinlock, which IMHO may cause concurrency problems on SMP boxes (?)

Re:Mostly compatible, but...

[powerlinekid]

All configurations of the following processor architectures have been declared obsolete:

Matsushita MN10200, mn10200-*-*
Motorola 88000, m88k-*-*
IBM ROMP, romp-*-*
Also, some individual systems have been obsoleted:

Alpha
Interix, alpha*-*-interix*
Linux libc1, alpha*-*-linux*libc1*
Linux ECOFF, alpha*-*-linux*ecoff*
ARM
Generic a.out, arm*-*-aout*
Conix, arm*-*-conix*
"Old ABI," arm*-*-oabi
StrongARM/COFF, strongarm-*-coff*
HPPA (PA-RISC)
Generic OSF, hppa1.0-*-osf*
Generic BSD, hppa1.0-*-bsd*
HP/UX versions 7, 8, and 9,

Re:Mostly compatible, but...

[red_dragon]

Intel 386 family

According to the changelog, i386 support (and source) will be removed in 3.4 unless someone tries to revive it.

Say what?? Don't you mean that only support for Windows NT 3.x has been obsoleted within the x386 family, which is what the changelog actually says?

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.

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.

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

Re:Two things I don't understand.

[Anonymous Coward]

The preprocessor no longer accepts multi-line string literals.

Why was this removed?

Link to GCC mail archive on this topic [gnu.org]. It seems like overkill, for sure.

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?

No. The funcionality is still there, it's just included via <stdarg.h> instead of <varargs.h>.

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:Two things I don't understand.

[spakka]

The preprocessor no longer accepts multi-line string literals.

Standard C doesn't allow newline characters in strings. You can still put in '\n' escape characters to represent newlines.

Does it mean we can't write void somefunc(int argc, ...) style funcs any more?

You can, but in the implementation, you need to use the Standard C header stdarg.h instead of the traditional C header varags.h.

Re:Two things I don't understand.

[norwoodites]

You can write that code but not:

char *A="A
B";
char *B="B";
char *C="C";

Anymore see how much problems this can cause if you did not have the second quote on the thrid line?

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.

Re:Two things I don't understand.

[norwoodites]

The first one was removed because of the extension was causing more harm than good, so you have to change all the inline asm, not to have multi-line strings.

The second is taking about the `varargs.h' header, the orginal way of doing variadic functions.

Maybe it means varargs.h

[r6144]

If you use stdarg.h, nothing should break.

I think here "the header" means "varargs.h", which is the old way for writing variadic functions. Should not appear in any reasonably new (post 1995) code.

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

Re:SuSE already uses it

[dizzy tunez]

Read "PRERELEASE" , not "RELEASE".
Yes, there is a diffrence.

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.

Should be quite stable

[r6144]

Vendors like SuSE does MUCH testing on their own, so the resulting thing should be reasonably stable. Anyway, official gcc releases are done on planned dates if there are no known showstoppers, and vendors can check them too.

Of course, if you want a REALLY reliable compiler, don't use a dot-zero release, whether the official release or the one from a dot-zero release of a distribution.

Compile-time performance

[Hortensia Patel]

Yes, this release (like all 3.x releases) is a lot slower than 2.9x was. This is particularly true for C++, to the point where the compile-time cost of standard features like iostreams or STL is prohibitive on older, slower machines. I've largely gone back to stdio.h and hand-rolled containers for writing non-production code, just to keep the edit-compile-test cycle ticking along at a decent pace.

The new support for precompiled headers will help to some extent but is by no means a panacea. There are a lot of restrictions and caveats. The good news is that the GCC team are very well aware of the compile-time issue and (according to extensive discussions on the mailing list a few weeks back) will be making it a high priority for the next (3.4) release.

Incidentally, for those wanting a nice free-beer-and-speech IDE to use with this, the first meaningful release of the Eclipse CDT is at release-candidate stage and is looking good.

Re:Compile-time performance

[Ed Avis]

I wonder, with the increase in CPU speeds since 2.9x was current, whether a $500 machine now can compile faster or slower than a $500 machine a few years back.

Of course it would be still nice for gcc not to get slower, or maybe even to get faster :-(.

Re:Compile-time performance

[MikeTheYak]

It's a meaningless question if one obeys the standard and the other does not.

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.

gcc 3.x compilers have serious C++ perfs issues

[ondelette]

The new breed of gcc compiler are anywhere from 3 %to 5% slower [gnu.org] with file processing using the C++ library. So, compiling the kernel with gcc 3.x is fine, but I suspect that something like KDE which is mostly written in C++ is impacted seriously. At least, all software using the C++ library for IO (fstream) will be much slower. On the other hand, the support for C++ standards is much better so what I do is that I compile using gcc 3.2.3 to validate my C++ and then I run the real thing with a pre 3.x compiler.

Re:gcc 3.x compilers have serious C++ perfs issues

[norwoodites]

The changes that made C++ compiling slower were for correctness of the compiler so they are needed. I know 3.4 will be faster than 3.3 is(/was), and should be able to speed up even faster.

Re:gcc 3.x compilers have serious C++ perfs issues

[dsplat]

I would not consider 3-5% a serious impact unless it came completely without other benefits. The bug report you linked to talks about a runtime performance impact of 2-5 times slower, not 3-5%. Nobody is going to accept an impact like that except to fix serious bugs in the generated code.

Re:gcc 3.x compilers have serious C++ perfs issues

[Fzz]

We're using g++ with heavy use of templates in a project that currently has ~400,000 lines of code. gcc 3.2.1 takes about 50% longer than gcc 2.95.4. But, gcc 3.2.1 found loads of bugs that gcc 2.95 didn't notice, even with all the error checking enabled. I'd much rather have the extra checking and have to upgrade my compilation machines 6 months earlier, rather than have stupid errors go unreported by the compiler. So far today it looks like gcc 3.3 finds still more bugs in our code than 3.2.1 did.

Than

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

getc_unlocked

[r6144]

On a linux system, if you want high performance, use getc_unlocked() instead of getc() (which does implicit locking on the stream), and do the locking explicitly if your program is multi-threaded. This is a glibc extension, so you must check its availablity before using it.

As for the mmap option... IMHO it is a little bit complicated, and glibc seems to use mmap on read-only streams anyway.

Everyone loves GCC?

[Call Me Black Cloud]

Not for me, thanks. I prefer the dynamic duo of Borland's C++ Builder/Kylix. Cross platform gui development? How you say...ah yes...w00t!

For Java, Sun One Studio (crappy name)/Netbeans (inaccurate name) floats my boat. There is a light C++ module for Netbeans but I haven't tried it...no need.

Give Kylix a try [borland.com] - there is a free version you know:

Borland® Kylix(TM) 3 Open Edition delivers an integrated ANSI/ISO C++ and Delphi(TM) language solution for building powerful open-source applications for Linux,® licensed under the GNU General Public License

Download it here [borland.com].

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.

Re:

[account_deleted]

Comment removed based on user account deletion

nonnull function attribute

[dimitri_k]

If anyone else was curious to see an example of the new nonnull function attribute, the following is reformatted from the end of the relevant patch [gnu.org], posted to gcc-patches by Marc Espie:

nonnull (arg-index,...)
nonull attribute
The nonnull attribute specifies that some function parameters should
be non null pointers. For instance, the declaration:

extern void *
my_memcpy (void *dest, const void *src, size_t len)
__attribute__ ((nonnull (1, 2)));

causes the compiler to check that, in calls to my_memcpy, arguments dest
and src are non null.

Using nonnull without parameters is a shorthand that means that all
non pointer [sic] arguments should be non null, to be used with a full
function prototype only. For instance, the example could be
abbreviated to:

extern void *
my_memcpy (void *dest, const void *src, size_t len)
__attribute__ ((nonnull));

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

Note: I didn't change the wording above at the [sic], but I believe that this should read "all pointer arguments" instead.

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.

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:Intel C++ Compiler 7.1 Rules

[Anonymous Coward]

I believe that the 7.x versions can now compile the kernel, and Intel have benchmarks to show it.

Of course as always, Gcc is still your number 1 choice for anything other than x86 compilation.

Re:Intel C++ Compiler 7.1 Rules

[be-fan]

Actually, GCC is really close to Intel C++. If you check out the benchmarks [coyotegulch.com] it's neck-and-neck on most code except for some Pentium 4 code and some numeric code. These differences are mainly due to Intel C++'s better inliner and automatic vectorizer. I do agree, though, that Intel C++ rocks. It's free for personal use on Linux, very GCC compatible, and almost as conformant as GCC to the C++ standard. It's also got extremely good error messages, which very important for C++ programmers.

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

Another one? WHY?!!!

[swordgeek]

OK, I'm not a developer. I don't write code--I compile it when the tools I need as an admin aren't available as trusted binaries.

Why, for the love of god, is there a new version of the de facto standard C compiler every week or two? Why can't binary compatability be maintained? WHAT sort of changes and development occur in the land of compiling a language that (as far as I know) isn't changing??!!

This isn't a rant--these are serious questions. I don't understand why so many changes are being done to a com

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 u

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:this is all well and good

[Anonymous Coward]

There is one. Its called Visual SlickEdit, it costs $249 dollars.

Re:this is all well and good

[Lumpy]

There is one. Its called Visual SlickEdit, it costs $249 dollars.

Oh man dont spend that money....

anjuta [sourceforge.net] is better and much more useable than visual slickedit as a linux based GCC ide for C and C++ and will create your project's Makefiles and everything else automatically.

I've used it for 6 months and it's easier than anything microsoft has ever written in their IDE and is certianly better than slickedit when you compare the costs.

I strongly reccomend that EVERY programmer download and try it right now

Re:this is all well and good

[dead_penguin]

except I WANT color highlighting to be printable! why is it that no programmer's editor cannot print the highlighting in color?

Could that be because most programmers don't really do that much printing of code? I haven't printed out any source since my form-feed dot matrix printer died years and years ago.

That said, pipe your code through GNU enscript [people.ssh.fi] to print it, and it should generate some decent syntax hilights. Also, if you're interested in publishing code with hilighting to a web page, Vim can outp

Re:this is all well and good

[REBloomfield]

erm... KDevelop? Amongst others, there's quite a few good ones now.

Re:this is all well and good

[jmccay]

Apperently KDevelop is just about as good. When I was looking into it, and they have scripting in it. I loved scripting in Visual studio.

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 relea

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

Re:this is all well and good

[AT]

The GNU make has this bug even worse, since it only checks file size most of the time.

False. GNU make checks the last file modification time. If you have any problems getting consistant incremental builds, it is probably because the Makefile has incorrect dependency information. For example, if a header file changes the size of a struct, every source file that includes it should be recompiled. An automated tool like "gcc -MM" is the best way to ensure the dependencies are correct.

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:this is all well and good

[BigBadBri]

Flamebait?

Nah.

Funny as hell, though - Visual Studio is an absolute joy to use.

Compared to what?

Having your head nailed to a table?

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:this is all well and good

[ArmorFiend]

If you get hopelessly confused, you could try a mailing list. If you write a good question, its highly likely the original developers will respond.

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: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:this is all well and good

[Dan-DAFC]

...I can tell you with certainty that Visual SourceSafe 6.0 is a steaming pile of dog turd that needs to be exorcised, not bug fixed.

Amen. I wouldn't have thought it possible to write a product that makes CVS look like a sensible choice for source control if I hadn't seen it with my own eyes.

We used to use SourceSafe, now we use CVS. CVS is an horrific train-wreck of an application but compared to VSS it's a triumph of software engineering.

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]

Re:slower than the last release....

[gazbo]

Sir, as the chairman for The Society of Prevention of Apostrophe Abuse, I must herby report your post's heinous abuse in the "word" wan<deleted>t. Expect a letter from our solicitors very soon.

Re:Precompiled header support

[oliverthered]

look here [gnu.org]

Using Precompiled Headers
Often large projects have many header files that are included in every source file. The time the compiler takes to process these header files over and over again can account for nearly all of the time required to build the project. To make builds faster, GCC allows users to `precompile' a header file; then, if builds can use the precompiled header file they will be much faster.

Re:Precompiled header support

[norwoodites]

look at http://gcc.gnu.org/ [gnu.org] and see under January 10, 2003:
Geoffrey Keating of Apple Computer, Inc., with support from Red Hat, Inc., has contributed a precompiled header implementation that can dramatically speed up compilation of some projects.

GCC will have it for 3.4.

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:Precompiled header support

[Anonymous Coward]

Yes. Precompiled headers make much sense for projects that do not include everything.

Including everything into a precompiled header file will infact make the compilation much slower than if you didnt use precompiled headers at all.

<windows.h> is a very bad example on how to make an efficient precompiled header. Granted, it may been what started the entire precompiled header business, but the time won from precompiled headers in general is greater than what you'd think.

The key to create a good preco

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

[HopeOS]

I am reminded of a document describing how compilers are like women and assemblers like men. Googled for it, but didn't find it.

The line I remembered was "things you've been doing for years that seemed OK are now suddenly wrong." I consider myself a pretty astute programmer, but every new compiler version seem to have some new warning to add.

As a result, I consider my relationship with my compiler no less volatile than that with my wife. Keeps me on my toes anyway.

-HopeOS

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.