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

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

[Anonymous Coward]

my bad, it has to be glibc 2.3.2 fails to compile with gcc 3.3

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]

I think the problem here is that we're told that "Linux" is the kernel and that "GNU" is the OS toolkit. "GNU" includes GCC and glibc, but not XFree86, Mozilla, or OpenOffice(though they may be under the same license).

If this version of GCC is to be considered unstable, then fine. Cause bustage. If it's supposed to be production ready, though(and you would think it would be since it's on the FP of /.), then I'd want it to work with the rest of "GNU."

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

[Anonymous Coward]

Why hold back for linux when all the other OS's work just fine. It is only a problem with that steeming pile called glibc.

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

[Anonymous Coward]

Felix von Leitner, is that you?

np: Curve - Falling Free (Aphex Twin Remix) (Aphex Twin - 26 Mixes For Cash)

Re:gcc 3.3 fails on glibc 2.3.2

[Anonymous Coward]

Still no fix for bug 8610. Large file support (> 2GB) has been broken for iostream since at least GCC 3.2

I'd post a link, but the URL for items in the GCC database is 677 character long and crashes mozilla when I paste it!?! Another search yielded a URL 1007 charaters long. And you don't seem to be able to search specifically by bug number.

So try this: GCC Bug Database Query Page

Category: Libstdc++
Severity: Serious
Priority: Medium
Responsible: Paolo
State: Analyzed
Class: sw-bug
Synopsis Search: 32-bit

Re:gcc 3.3 fails on glibc 2.3.2

[Anonymous Coward]

While I agree in principle, it's only been relatively recently that you could build the kernel with a recent version of gcc.

Re:gcc 3.3 fails on glibc 2.3.2

[Scarblac]

Those are third party projects.

GCC is the C compiler of the GNU project, glibc its C library. Those are the first things that should work together...

Re:gcc 3.3 fails on glibc 2.3.2

[norwoodites]

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

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

[nr]

If glibc break due to crappy programmers unable to follow the ISO C standard its their fault. The glibc team should fix their buggy code, not hassle the GCC team with ugly workarounds.

Big greets go our to all GCC developers/testers making the 3.3 release possible!

Re:gcc 3.3 fails on glibc 2.3.2

[Anonymous Coward]

Thanks!
Whenever I get to it via the query page I get an enormous URL. How'd you find this?

Re:gcc 3.3 fails on glibc 2.3.2

[SexyAlexie]

They really shagged the dog on this one..

[alex@slut]/home/alex/src/sizetest > ./sizetest-2.95.3
sizeof(std::streamoff) = 8 bytes (64 bits)
sizeof(std::streampos) = 8 bytes (64 bits)

[alex@slut]/home/alex/src/sizetest > ./sizetest-3.2.2
sizeof(std::streamoff) = 4 bytes (32 bits)
sizeof(std::streampos) = 12 bytes (96 bits)

Oh dear!!

Re:gcc 3.3 fails on glibc 2.3.2

[Master Bait]

That's right. GCC is BUG FREE and if your software doesn't compile, it's because of your crappy code!

Re:gcc 3.3 fails on glibc 2.3.2

[Anonymous Coward]

XFree86, Mozilla, or OpenOffice(though they may be under the same license).... which they're not.

Re:gcc 3.3 fails on glibc 2.3.2

[Anonymous Coward]

GCC team == GLIBC team == RedHat

So none of this matters until Linux 10.0 ships.

Re:gcc 3.3 fails on glibc 2.3.2

[norwoodites]

In the release notes for gcc 3.3, there is a note about accessing PR's.

Re:gcc 3.3 fails on glibc 2.3.2

[GlassHeart]

This is because many kernel rely (unintentionally) on some behaviour of gcc that is not guaranteed by the standard.

Really? I would consider that to be terrible code. It's one thing to intentionally rely on compiler quirks, because sometimes you really don't have a choice. It's another entirely to not even know that your code relies on a particular version of the compiler. An unintended portability problem is a bug, produced by a programmer who doesn't know his or her language!

Absent proof of many portability bugs in Linux, I don't think your assertion can stand.

Re:gcc 3.3 fails on glibc 2.3.2

[Arandir]

But glibc is not a core system component of any system other than Linux (and the semi-mythical Hurd/GNU).

GCC-3.3 will compile the kernel and libc on my Free Software operating system, so it's no problem for me.

Re:gcc 3.3 fails on glibc 2.3.2

[stephenb]

libstdc++ != gcc

Re:gcc 3.3 fails on glibc 2.3.2

[SexyAlexie]

You can't build C++ apps with large file support in GCC 3+. Not good.

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

[p3d0]

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.

Really? That's a shame. One of the things I used to like about gcc is that it would bloody well inline something if I told it to. I once had an application that ran 10 times slower with Intel's compiler because it didn't inline what I told it to.

Re:gcc 3.3 fails on glibc 2.3.2

[GlassHeart]

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

I see. I was confused by the way you phrased the statement, which made it sound like there were many cases of relying on compiler quirks without meaning to, which is just sloppy. Bugs are of course a fact of life, but they should be few and far in between for a mature product like Linux.

Re:gcc 3.3 fails on glibc 2.3.2

[Anonymous Coward]

You are a loser among losers if you scripted a "now playing" pseudosig in your slashdot posts.

Re:gcc 3.3 fails on glibc 2.3.2

[jmv]

There may be a (non-standard) way to get that behaviour back. However, gcc is still compliant with the standard and I'm guessing there's probably a good reason for the change.

Re:gcc 3.3 fails on glibc 2.3.2

[dhazeghi]

Wrong. More than half of the active developers of gcc are at other companies. IBM, Apple, Codesourcery, and others. Heck, a good number are volunteers too. All the more reason to bash them, I suppose...

Re:gcc 3.3 fails on glibc 2.3.2

[Anonymous Coward]

there's a flag to control whether inlining is always/never, or under what circumstances.

there are a LOT of useful options if you run /usr/local/lib/gcc-lib/..../cc* --help.

Re:gcc 3.3 fails on glibc 2.3.2

[Anonymous Coward]

The compiler should be compliant with C99 and whatever other standards (C88?). It should NOT have to be twisted to fix other peoples bugs. That's THEIR problem.

Re:gcc 3.3 fails on glibc 2.3.2

[stephenb]

Yeah, I get that, it is bad. But it's not a GCC issue, it's a libstdc++ issue. This article is about a new release of GCC, not libstdc++. The OP is acting as if a new release of GCC should have fixed a bug that is strictly a libstdc++ bug. I was attempting to point this fact out in a succinct manner. Obviously I needed more words.

Re:gcc 3.3 fails on glibc 2.3.2

[Anonymous Coward]

GCC was right, the kernel was broken. No object can simultaneously be an int and a float, so accessing it as both is always undefined behavior. If you want unions you know where to find them, but even then you have to be consistent about reading only as what you last assigned (int or float).

Re:gcc 3.3 fails on glibc 2.3.2

[JAKJ]

Don't troll. The poster said *IF* it is due to crappy code. I am personally against all non-hardware bug workarounds, because it just encourages those bugs to stay. Honestly, unless you are in an emergency situation and not using the software isn't an option, why should the compiler even *allow* language violations? Why even bother with a language? Say "this code comes from my intense psychic powers and if your system can't use cosmic rays to figure out what even I didn't intend, it's your fault"!?

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?

Re:gcc 3.3 fails on glibc 2.3.2

[The Smith]

The Linux kernel uses virtually every feature of gcc there is, that's why it's the traditional stress test. There will always be little inconsistencies and changes in how the compiler behaves, but because the kernel uses a lot of unusual features it's much more likely to be affected than a user-mode program.

As far as I know, the currently recommended compiler for building the kernel is 2.95.3. Using the 3.x releases is dodgy at best, and there was never really any chance that 3.3 would work straight away.

Re:gcc 3.3 fails on glibc 2.3.2

[rabidcow]

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.

Even if it does you're not very well off. Optimally it would refuse to generate any code at all when you aren't following the language perfectly.

Re:gcc 3.3 fails on glibc 2.3.2

[SexyAlexie]

Put like that, yes, you'd be right. But still it's quite a bad regression from 2.95.3.

Re:gcc 3.3 fails on glibc 2.3.2

[juhaz]

So it should work with all the gnu projects at all costs even if they're full of broken and noncompliant code? Just because they've got the word GNU in their name? Wow. Quite a requirements you have there.

How about I'd want it to work with what C-compiler is supposed to work. C code, that is. Good C, standard compliant C, and screw all code that isn't exactly that, GNU or not GNU.

GCC 3.3

[Anonymous Coward]

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

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

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.

Re:SERVAR == TEH VARY SLWO

[Anonymous Coward]

I guess it means that Windows NT 3.x (on any processor) is not supported.

Re:SERVAR == TEH VARY SLWO

[dhazeghi]

Mingw32 is still supported, and probably will be for a long time to come. As is cygwin.

Re:SERVAR == TEH VARY SLWO

[Anonymous Coward]

That's what i wanted to know. Not the smartass remark that NT3.0 is not supported.

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

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

Re:Sigh

[unixmaster]

Maybe the kernel is buggy but what about increasing c++ compile time regressions since gcc 3.0 ?

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

[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:Sigh

[unixmaster]

Well testing is helping too just got my gcc-3.2.3-gcc-3.3 patch. I have latest 2.5.x kernel so I can try and report any failures. Btw I did not mean to say gcc 3.3 does suck or anything like that its just they are postponing bugs to get a release done that hardly makes a user happy. I would wait for more if they promised to fix c++ compile time regression.

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

Re:Sigh

[r00zky]

I bet that will be fixed in 3.4, with the inclusion of precompiled headers...

see gcc 3.4 projected changes here

Re:Sigh

[pixelbeat]

This is a gcc bug IMHO:

Re:Sigh

[aes12]

From the Linux Kernel HOWTO:

5.4. What version of gcc and libc do I need?

Linus recommends a version of gcc in the README file included with the linux source. If you don't have this version, the documentation in the recommended version of gcc should tell you if you need to upgrade your libc. This is not a difficult procedure, but it is important to follow the instructions.

From the kernel 2.4.20 README file:

Make sure you have gcc 2.95.3 available. gcc 2.91.66 (egcs-1.1.2) may also work but is not as safe, and *gcc 2.7.2.3 is no longer supported*.
Also remember to upgrade your binutils package (for as/ld/nm and company) if necessary. For more information, refer to ./Documentation/Changes.

Now, why on earth would anyone think that it's either of thier faults that the new gcc won't compile the kernel. Linus has told you that it probably won't...

Re:Sigh

[Anonymous Coward]

Is it me or gcc team goes for quantity rather than quality

You're kidding, right?

Take a look at the release criteria:
http://gcc.gnu.org/gcc-3.3/criteria.htm l

They do extensive testing on multiple platforms. I've yet to see another open source/free software project that is as organized and anal about bugs and regressions as GCC is.

You'll notice that the release criteria include compiling the linux kernel, version 2.4.18. So at least that version is known to compile and test correctly. Whether they used the "correct" options/tests is a different question.

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

[Anonymous Coward]

To my knowledge, yacc cannot build recursive descent parsers, only shift/reduce parsers. So you get a difference just from the change in architecture alone.

As with all things, though, a well-written (machine) code generator should beat out hand-written code.

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.

Re:Sigh

[Anonymous Coward]

Your point about helping out is valid, but saying that it's mostly volunteers isn't true. Subscribe to the GCC lists and see where most of the posts come from...

Re:Sigh

[t]

It is a point release. Perhaps you should wait till 4.0? It might be awhile though. The reason they do more point releases is because they don't want to get caught in the trap that killed the original gcc project (do recall that the current gcc tree is the egcs fork that became the official tree).

Re:Sigh

[Anonymous Coward]

Why does the kernel depend on undocumented extensions? That is what the Intels and Microsofts do. How careless for linux!

Re:Sigh

[Anonymous Coward]

Lcc uses a handwritten parser and lexer, and is one of the fastest ansi-C compilers available.

Re:Sigh

[TrekkieGod]

why do you not help them and fix some problems, and/or report some problems to us (I am slowing helping out now)

You're slowing helping out? Is that a job in tech support that I was unaware of? How do you do that? Do you ask the people reporting the problem obvious questions? Do you refer them to useless documentation that doesn't relate to your problem? Darn!!! That's why microsoft's tech support doesn't work...I keep reaching the people hired to slow the helping out, rather than help.

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?

Re:Bounds Checking

[Anonymous Coward]

Nah, it has had bounds checking now for a
long, long time.

g77 -fbounds-check ... :-)

Re:Bounds Checking

[Mitchell Mebane]

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.

Sorry, I just couldn't resist the urge to indert a plug for Gentoo. :P

On Gentoo, doing this is a time-consuming, but rather trivial task. Type emerge -e world, go on vacation for a few days, and find everything working again.

Re:Bounds Checking

[juhaz]

On every sane distro this is a very trivial and not that time-consuming task. Type up2date, apt-get update && apt-get upgrade, or something similar, then go for a cup of caffee and come back after few minutes and find that everything is working again.

Nice, isn't it? No need to wait for two days for your stupid *%FD%#:"%#:n excuse of a distro to compile.

Guess one can never understand gentoo loonies.

Be careful

[swagr]

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

Re:Be careful

[Anonymous Coward]

I can't believe someone was stupid enough to think my post was a troll. As if I'm really "waiting for SCO", or expect anyone to think I am.

I was pondering, while writing the post, if I should surround it with tags. It turns out I have once again overestimated the intelligence of the average Slashdot moderator.

Re:Be careful

[JAKJ]

If you don't mean what you say, don't say it. If you say what you don't mean and you get slammed for it, take it like you deserve it or go win yourself a Darwin award.

Re:Be careful

[swagr]

Anyone who knows anything knows that there is no information about horses in the word "horse". Yet we use the word anyway when what what we actually mean is our idea of what we think the the second party's idea of a horse is.

You see, communication is much more than what you seem to think it is. Part of the charm of being human is that we can say things other than what we specifically mean, and a smart person on the other side of the communication will still understand what we mean. In short, we are not idiots.

It seems like you didn't know this, so let me give you a few pointers:
Victory, contrary to what you may have heard, does not have a taste (sweet or otherwise).
And when someone says "I'll call you later", you aren't witnessing an act of a psychic foreseeing the future. What they mean is "At this moment I beleive that in the future I will make an attempt to call you."

Anyway, I'll let you look into this for yourself.

Stricter Checking - Programmers Check Your Stuff

[wol]

I believe this version has stricter checking. It is probably a good idea for everyone with programs out there to do a quick recompile and see if there is something you can improve or error messages you can fix.

ABI?

[42forty-two42]

Does this release break binary compatibility?

Re:ABI?

[Anonymous Coward]

No.

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

[REBloomfield]

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

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

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:slower than the last release....

[Anonymous Coward]

You Sir, bit.
Have a good day.

Re:slower than the last release....

[Anonymous Coward]

herby
\Herb"y\, a. Having the nature of, pertaining to, or covered with, herbs or herbage.

Re:slower than the last release....

[Anonymous Coward]

Expect a letter from our solicitors very soon.

Soliciting is illegal in the US, except for some counties in Nevada. Usually they spell it out on the arrest warrent, like so: ``soliciting for prostitution''.

Re:slower than the last release....

[JAKJ]

Soliciting means you're just trying to sell something. Don't you notice "no soliciting" signs near apartment complexes? That means "no vaccuum-cleaner salesmen" as well as "no prostitutes". :P

Re:slower than the last release....

[Anonymous Coward]

laughing my ass off...

/. is pure entertainment.

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

[Anonymous Coward]

Visual Studio will cost you $100-1000 depending on version and features. Windows is similarly, not free.

Some options:
CRiSP costs $150.
Look into what Borland has.
Develop Lisp apps using Emacs.
Develop Java apps using IntelliJ Idea (put's other IDE's to shame).

Re:this is all well and good

[Anonymous Coward]

Get Borland's Kylix. Besides, having to use a specific tool to generate code and do your work for you doesn't make you a programmer, you're just another user of someone else's program. You have to see stuff in your head better than what Winblows visual does before you can call yourself a programmer, Bunky.

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

[Ed Avis]

But if your C++ code today obeys the standard, and the code you wrote three years ago did not...

I agree though, standards compliance is more important than compilation speed.

Re:Compile-time performance

[jmccay]

For a good IDE for Windows that's free try Dev-C++ over at source forge. It's just an IDE but you can get it prepacked with Mingw 3.2 (gnu c++ 3.2). It's great and improving everyday.

Re:Compile-time performance

[Hortensia Patel]

I looked at Dev-C++ a couple of years ago, at which point it was largely useless for anything but toy projects. (IIRC, it insisted on opening every single file in the project at startup - heh.) Has it improved a lot since then? Maybe time for another look, though I'm pretty sure I'll be moving to Eclipse now.

Re:Compile-time performance

[natmsincome.com]

Here's some tools you might want to look at. I found them right at the end of my last Job using C++ and wish I'd found them at the begining. Together they can really cut compile time down.

CCache http://ccache.samba.org/ this can make make project build almost 6 tines as fast on following compiles. This isn't very good for doing a ./configure, make, make install but great when you are developing something.

DistCC http://distcc.samba.org/ use everyones computer to compile the project.

So if your having slow compile times in a development environment use these to decrease them.

If at first you don't succeed, don't go sky diving.

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.

So, kids, don't try this at home (yet)

[Anonymous Coward]

In other words, if you don't have some special reason (developer, tester, guru, itch up the arse) to try it, don't. The newbs often rush in to try a new sparkly piece of software just because. But when that particular piece of is a compiler, you're better off waiting a few months until software projects mantainers pick up on the changes.

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.

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

[ondelette]

The new breed of gcc compiler are anywhere from 3 %to 5% slower 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

[Anonymous Coward]

Also note that large file support (>2GB) using iostream is broken since at least GCC 3.2 See bug 8610 (libstdc++, sw-bug, responsible: Paolo)

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.

Thank you gcc team!!!!

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

[Magura]

Now, call me wacky, but a compiler isn't really a good bug checking tool.

Sure, like most people, I get lazy and run code past a compiler kinda like I'd use a spell checker - but using your compiler to find bugs ... that makes me squirm in my seat.

Don't get me wrong, I also think going the other way to the point where code should be hand checked as to not produce any warnings/errors on the first compile is a bit silly (Capability Maturity Model kind of thing), and I would also assume the parent poster doesn't use gcc as the only way of finding those kind of bugs, but lint, splint, valgrind and similar is a much better choice than hoping the compiler gets it.

But then, I refuse to use that pig called C++, so what would I know :)

insane

[Anonymous Coward]

You write your own containers because STL compiles
too slow?! I guess you don't value your time AT ALL.

Re:insane

[Hortensia Patel]

I think you missed the "for writing non-production code" qualifier.

For a small, non-critical app which only needs minimal functionality, hand-rolling is hardly a time sink. Writing a bare-bones string or list implementation takes about five minutes, and in terms of time, will "pay" for itself after a dozen or so compiles.

Re:insane

[Anonymous Coward]

You're a fucking moron. Just buy a faster computer, loser. Do you think people that develop for M68000 develop on M68000?

At last

[Anonymous Coward]

Vax VMS has been obsoleted!

Re:At last

[ciaran_o_riordan]

Vax users everywhere are crying. All eight of them.

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?

[Anonymous Coward]

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

Avoid it like the plague unless you are a developer dabbling in the black arts of GCC.

"BTW, there is a preliminary ebuild in Gentoo"

Is that asking for trouble or what?

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?

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

[stripes]

In the short run, nothing changes.

Isn't the DFA pipeline schedular much better at producing fast code for VLIW and wide issue super scaler CPUs? (and if the P4 isn't "wide issue", it at least deals with knowing which instructions use which pipelines better then the old scheduler).

I would expect at least some speedups on most superscaler CPUs (i.e. the P1, P2, P3, P4, the AMD K7, the modern and somewhat old PowerPC and SPARCs). Not huge ones since there was a superscaler scheduler before, but the new one is better.

Re:What does it mean?

[dhazeghi]

Yes and no. In theory it's much better. But you have to take advantage of it in the processor descriptions. To date, there hasn't been too much effort on that front. I think only Hitachi SH has had a significant improvement in codegen so far.

Re:What does it mean?

[chez69]

Actually, it's great. The gentoo wankers who compile everything can test it while the users who get real work done can get a much more stable build later.

Mostly compatible, but...

[r6144]

According to this, 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...

[Anonymous Coward]

In plain english please - will this new GCC break any versions of RedHat, Mandrake, Suse, Slackware?

Re:Mostly compatible, but...

[DarkOx]

I think the answer to your question in plain english is:
"Maybe, if those are being run on an SMP box"

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, hppa1.[01]-*-hpux[789]*
HiUX, hppa*-*-hiux*
Mach Lites, hppa*-*-lites*
Intel 386 family

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

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

[Ioldanach]

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?

Search the changelog for the phrase "Intel 386 family". Looks like its in there to me, if I'm reading it right.

Re:Mostly compatible, but...

[Ioldanach]

Search the changelog for the phrase "Intel 386 family". Looks like its in there to me, if I'm reading it right.

Oh, ok, serves me right for reading the list as a slashdot entry before checking the original source. Looking at the original source list I see that the phrase "Intel 386 family" is a section heading with NT as its only contents. I imagine the original poster didn't check the original list, either, and made the same error I did.

That's what results when someone posts the contents of an article instead of a link to it, I guess.

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.

Re:Mostly compatible, but...

[m0rten]

Otherwise when the code is mixed, the bus isn't locked when accessing the spinlock, which IMHO may cause concurrency problems on SMP boxes (?)

I might be way wrong here, but I thought the SMP machines had cache-coherence so that this sort of problem shouldn't occur?

Re:Mostly compatible, but...

[Anonymous Coward]

No one except for Debian and a few other distributors.

Re:Mostly compatible, but...

[Cleveland Steamer]

• I might be way wrong here, but I thought the SMP machines had cache-coherence so that this sort of problem shouldn't occur?

Consider a 2-processor system with no caches where both CPUs simultaneously execute a read-modify-write instruction (for example, OR) on the same location in memory. Without bus locking (the LOCK prefix in the x86 instruction set) you have no guarantee that both processors execute the RMW operation atomically.

Let's say CPU0 executes "orl $1, ptr" and CPU1 executes "orl $2, ptr". If the 32-bit value at ptr is initially 0, you would expect the resulting value to be 3.

1. CPU0 reads ptr and sees 0
2. CPU1 reads ptr and sees 0
3. CPU0 ORs the 0 with 1 and gets 1
4. CPU1 ORs the 0 with 2 and gets 2
5. CPU0 writes its result (1) to ptr
6. CPU1 writes its result (2) to ptr

In the above situation, ptr ends up with an incorrect value because the operations did not complete atomically.

Re:Mostly compatible, but...

[HuguesT]

i386 is alive and well in the embedded market, which has been a strong supporter of gcc for a very long time.

Just as I thought...

[Anonymous Coward]

...the Installsheild Windows binaries are nowhere to be found. Sigh....

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?

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

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. It needs the GNOME libs though.

Re:Everyone loves GCC?

[blahtree]

Kylix sounds great, but in practise it isn't very useful. Kylix 3 is the first release to support C++, and as you can imagine, it is riddled with bugs. Linux support is NOT a priority for Borland. I moved back to gcc after finding that STL would cause internal compiler errors with Kylix. Blech.

Additionally, Borland's error messages are ridiculously uninformative compared to those of gcc. A little -Wall goes a long ways to catch things that Borland's compiler just will not catch. Borland's got a ways to go.

If you're making simple gui apps, cool, but if you are making anything of any complexity, stay far, far away!

Re:Everyone loves GCC?

[Anonymous Coward]

I prefer python/[tk,qt,wxwindows,gtk(pick your favorite)]. It's not only simple, but it takes very little time and is very, very portable.

Delphi reminds me of pascal (and yes, I know it's for good reason) which scares me to death so I prefer to not poke it with a 4 meter pole.

Re:this is all well and good

[Anonymous Coward]

Yeah, I'm going to take advice from someone using the phrase "winblows".

Face it dork, Visual Studio is pretty nice. Thousands of MS Coders use it every day. Probably there are more Microsoft employees using visual studio than there are total users of any of the IDEs you mention. If there's a bug, it gets fixed. If there's a feature they want, it gets added.

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: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 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... it's that good (except I WANT color highlighting to be printable! why is it that no programmer's editor cannot print the highlighting in color?)

Via C3 Ezra

[Simon Lyngshede]

They don't really seem to care about not following the standard for i686. You still have to compile everything for i586 on the Via C3 Ezra chips. The specs. for i686 states that cmov is an optional feature in i686 chips but gcc still doesn't check if the cpu supports it. Of cause with the new C3 it doesn't matter, but I don't have one of those.

Not a big fault, but it would be nice not having to remember to set the cpu type to i586 everytime you compile stuff.

Re:Via C3 Ezra

[pixelbeat]

Just run this script which handles that:

Re:Via C3 Ezra

[Anonymous Coward]

Why do you want to slow down users of real i686s? There are milions of P2+ or K7+ users, but only handfull Ezra users. Approach taken by GCC team is IMHO right.

VIA realized they did a mistake and Nehemiah is OK.

Re:Via C3 Ezra

[Simon Lyngshede]

No where does it say that a "real" i686 must have cmov, the compiler should check for cmov before using it. I wasn't talking about removing cmov completly, simply have the option of exclude the use of it when I compile things my self.

Naturally it should affect other i686 users, that would be dumb.

And yes very wishly Via added cmov to Nehemiah

Re:Via C3 Ezra

[Anonymous Coward]

How about you add a patch? That *can't* be core functionality or particularly difficult to fix, and then you and the other C3 people would be happy.

Re:Via C3 Ezra

[Anonymous Coward]

No, you have to compile everything for i486 for C3 (yes, even Ezra and Nehemiah) chips if you want to make sure everything works correctly.

The C3, like every chip Cyrix (and now Via) has come out with for years, is little more than a higher-clocked 486 on a better manufacturing process. It has the worst performance available in a current x86 processor.

Re:Via C3 Ezra

[cimetmc]

The main problem is that there is no i586 and i686. After the i486, Intel started calling their processors by names. Overall, there is a high ambiguity of when a processor is an i586 or i686, especially when it comes to non Intel processors and whether they support some specific instructions. The GCC developers realized that and therefore included -mcpu and -march options for a wide variety of cpu types. For compatibility reasons, the i586 and i686 options just alias to pentium and pentiumpro. If your processor is not 100% intruction compatible with an Intel Pentium or Pentiumpro, then you should better use a more approriate processor type when compiling.
If you check the available options at http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/i386-and -x86-64-Options.html , you will see that there is even a c3 option available.

Marcel

Re:Via C3 Ezra

[cimetmc]

Read the GCC documentation, and you will see that i686 is just an alias for Pentiumpro. If your processor does not support the cmov instruction, then it is not Pentiumpro compatible and i686 is the wrong option for you. The cmov instruction is the single most important additional instruction activated by -march=i686 . If you remove that instruction, you severely cripple GCC for all users of Intel processors of really compatible processors. If you want your code to be scheduled for i686, but not use the additional instructions, you can still do that using -mcpu=i686 and -march=i585 . So GCC already has all the options you need to properly compile your programs for any possibly minimum/optimal processor combination you want. Don't ask developers to cripple GCC just because you are using an incompatible processor.

Marcel

You need to do cost-benefit analysis of your time

[Anonymous Coward]

If you're hand-rolling containers and avoiding STL or iostreams because your box is too slow you're whacked.

What's a 2.0 gig barebones box cost now? $400?

How cheap do you work for that you can't afford a $400 tool that would free you to use ANSI and ISO standard code that you don't have to develop and debug?!?!?

Re:this is all well and good

[Anonymous Coward]

C++Builder is great if you don't need your IDE to be stable.

I've been using it professionally for almost 4 years.. I can tell you in no uncertain terms that it is junk. It's junk. See?

They can't write a solid GUI with their own GUI lib. That should tell ya something.

Thank god for vim and text .dfm files. I would have went insane long ago otherwise.

Re:this is all well and good

[Anonymous Coward]

Visual Studio is pretty nice...if there's a bug, it gets fixed. If there's a feature they want, it gets added.

I don't know about the rest of the Visual Studio products, but 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.

I expect Visual C++ or other Visual Studio products are a much better. I hope so, for the sakes of the developers who have to use them.

as opposed to $249 pounds?

[thornfield]

or maybe $249 yen, $249 francs?

Re:this is all well and good

[double_u_b]

I know about the clean and rebuild all. I tried. But it didn't work. In fact, all the problems began when I asked people to use the const keyword to prevent some side effects at compile time. Borland C++ Builder, at the time I used it, had the code completion thing. I don't know what code collapsing is. I suspect you are talking about Borland C++, not Borland C++ Builder. I used Borland C++ 4.5 and 5, those were buggy IDEs. Worst was Watcom C++ IDE. The text editor could hang the computer 4 times a day. But you use the compiler and IDE your company owns. But VC++6 never had my preference in one aspect: it produces faster code than borland compiler.

If you use fstreams you ain't into performance

[Anonymous Coward]

Geez, why not use getc() and putc() and process the file byte-by-byte?

If performance is important, do this:

int fd;
struct stat sb;
void *data;

fd = open(...);
fstat( fd, &sb );
data = mmap( NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0 );
close( fd );

// data processing here on *data

munmap( data, sb.st_size );

This will out-perform damn near anything.

Re:If you use fstreams you ain't into performance

[jmccay]

This is offtopic, but I like that code.
What systems does that work on and what headers are needed? That's the first time I seen someone memory map a file.

Re:If you use fstreams you ain't into performance

[Anonymous Coward]

Anything that complies to Unix98, which includes all actively maintained unix-like systems. Get the standard Unix references at http://www.unix-systems.org/version3/

Re:If you use fstreams you ain't into performance

[Minna Kirai]

It's a POSIX function, so it'll work on most Unixy operating systems. Check /usr/include/sys/mman.h for the prototypes.

Re:If you use fstreams you ain't into performance

[Mr Z]

It's a POSIX / UNIX way to do things. I'm not sure if the various Windows compilers support mmap. Under Linux and/or UNIX, you can do man mmap to find out more.

And yes, mmap is very cool. I've used it to great effect in a programming contest where speed was one of the measures. I mmaped the file and faulted it in quickly with a short loop. The overall program flew like a bat outta hell! What's really nice is that you can just refer to the file contents directly by pointer as opposed to reading them or freading them into a buffer. The downside is that it's less portable and harder to get right, which is why I don't use it for everything.

--Joe

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

[Abcd1234]

Well, spotting null pointers is only so useful anyway. My own intuition suggests that most pointer problems are related to pointers with undefined values in them. Either they weren't initialized in the first place, or they were free'd prematurely.

Besides, checking for NULL can be quite easily done at runtime using assert(). 'course, having the compiler do it at compile time will catch a few cases, and doesn't incur the (minor) performance hit of doing a runtime check, but it still strikes me as a narrowly useful feature.

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:nonnull function attribute

[mad.frog]

Um, and this is better than using a C++ reference... how?

Re:nonnull function attribute

[IcePic]

try this:
-----------
int a;
a=atoi(getenv("DONT_EXIST"));
-----------
to see a short piece
which would gain from this.
This will only fail when the variable DONT_EXIST
doesn't exist, which it obviously will in your
own comfy environment, but not in your customers,
from where the bomb will be clearly visible. =)

Re:nonnull function attribute

[spitzak]

It does sound equivalent, so I think the main advantage is that it can be used in languages that don't have references.

Re:nonnull function attribute

[TheRaven64]

C has had references since '99, pascal has had references since, umm, whenever, in Java everything is a reference. I've never used Fortran, so maybe that's what you are talking about?

Re:nonnull function attribute

[Abcd1234]

Yes, but in your example, this code is non-portable. One can't guarantee, on all compilers, or even with different libc's, that atoi() is making use of the nonnull attribute. IMHO, this feature is only really useful for user-written functions, and again, I would argue assert() accomplishes the same thing (and in a portable fashion).

Re:this is all well and good

[TrancePhreak]

Well that's rather odd then. I've had const all over the place in a couple projects and everything seemed to work just fine. I wouldn't throw out the possibility of the compiler misbehaving at this point, but I'd still guess it to be something else. Code collapsing is like being able to fold a piece of paper so that you only see the parts you want to. A lot of newer IDE's have this.

Sun One install hangs on my dual-proc box

[Anonymous Coward]

On a Slackware 9.0 box with dual processors the processes used to install the package wind up hanging on a wait4() call that's wait()'ing for a process that's already exited (confirmed with strace).

To install I had to boot a single-processor kernel.

Seems to be a kernel bug in the wait4() code. If I had the time to run down all the things kernel.org wants for a bug report I'd report it. But I'm using Sun One to generate paychecks right now...

Re:this is all well and good

[double_u_b]

I must say that when I first saw the code, it was really messy... So the cleanup was long and difficult. I remember the problem occured in a private static const function that dealt with the serial port. Code collapsing sounds a cool feature, but the VC++ we used (VC6) didn't have this. Now, I don't code in C/C++ anymore, or just for fun. I use the worst IDE I know of (even if it feature some kind of "code collapsing"): Cool:GEN to produce COBOL

Re:this is all well and good

[Anonymous Coward]

Visual Studio is shit, but lamers can't tell. They think it's wunnerful. I don't do Winblows, pal. I'm strickly an *ix person these days. I hack better code than any of you kiddies using Billie's VS, I have to have 100% no fail code for communications, and I quite doing Microsnot and M$ Visual when the code kept failing and BSODing all the damn time. I switched full time to *ix and haven't touched Bill's Wanker OS in over a decade. My pay is almost double what my former cube buddies are making still being a user of someone else's GUI maker program instead of usng their own brains to get the job done. Have nice life, M$ loser. Bill loves you and appreciates that you died for his sins.

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

[Anonymous Coward]

Yeah, but is it open source? No. Does it run on multiple platforms? No. Is it even free? (Yes, as long as you don't want support.) Who cares how good it is if it isn't open source and multi-platform? And I decided a long time ago that no software is good enough to pay for.

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

[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 page. The books are great and well worth the money. The art work isn't quite my thing. Does your employer match United Way contributions? Direct some of your giving to the FSF.

Re:Intel C++ Compiler 7.1 Rules

[be-fan]

Actually, GCC is really close to Intel C++. If you check out the benchmarks 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

[Anonymous Coward]

shrug ... say hi to RMS for me.

The Intel compiler buys me about a 20% improvement on my 1GHz PIII on C++ number crunching apps ... I expect even better on the P4 Xeon based cluster we're replacing our Alpha cluster with.

Time is money, and this will cut a day off a typical 5 day computational run. Maybe more if I get around to hand-coding some IPP stuff in there (with plenty of conditional compilation macros to keep it cross-platform/compiler) That software is good enough to pay for.

I like gcc, and use it alot. But I'm willing to pay for the best tool if I have to.

Re:Intel C++ Compiler 7.1 Rules

[Anonymous Coward]

It always comes down to the specific applications ... the intel compilers buy me about 20% improvement on my 1GHz PIII in some C++ number crunching apps.

Re:Intel C++ Compiler 7.1 Rules

[Anonymous Coward]

Most GCC work is now commercial and is not funded by the FSF. If you want to support GCC, go buy the commercially supported RedHat "GNUPro" GCC suite.

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

[Anonymous Coward]

Does it optimize well for the Athlons?

Actually, yes. Don't expect Opteron support though.

Re:Intel C++ Compiler 7.1 Rules

[Garen]

Those benchmarks you linked to aren't worth much. One thing to note thats not emphasized there is that the author was only able to get close by being told by a GCC insider about which of the zillions of knobs to turn just right for those benchmarks. Meanwhile, ICC optimizes extremely well by default and the "knobs" you need to know about can all be summarized nicely in a few-page listing by typing "icc -help." Contrast that to the practically encycopedic GCC manual that requires you to go through various backflips to tune apps. (And even then, GCC frequently misses optimization opportunities that it has support for, IME.)

The claim that ICC has poor error messages is just plain wrong. The EDG C++ front-end that ICC uses is the best there is. Period. This is widely known and even admitted by GCCers.

The error messages and warnings that ICC produces are in a league of their own compared to GCC. One thing inparticular that I find especially useful is it's ability to generate optimization reports and remarks about prohibitive dependencies in my software that prevents optimizations.

Another thing ICC has going for it is that it's way the hell more reliable (IME of course.) There's a damn good reason why -O2 is enabled by default when you run icc: it's a lot less likely to screw up your code, and it compiles fast even when optimizing -- faster with -O2 than gcc is at -O0!

To top it off, I can get it to do two-pass interprocedural optimizations with a simple "-ipo" flag. Thats a lot better way than concatenatting your source into one big giant blob like what KDE does atm.

Re:Intel C++ Compiler 7.1 Rules

[Garen]

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?

Yup. But not necessarily in the reverse. ICC doesn't support all of GCC's extensions, but enough of them to build the Linux kernel.

For the rest of us, the folks without intel CPUs

Considering that AMD uses intel's compiler to submit their own SPEC scores, I think you can include those too. Non-x86 stuff like MIPS/PPC/SPARC is out though, but I'm sure you knew that.

Re:Intel C++ Compiler 7.1 Rules

[be-fan]

Setting the right flags for GCC isn't exactly voodoo magic. A quick trip to the Gentoo forums is all it takes. And you only have to choose flags once.

Also, I think you misread my post. I was prasing ICC's error messages, not GCC's.

I would disagree that ICC is more reliable. It's aggressive inliner has broken more code for me than GCC's.

I do agree that the "-ipo" flag is rather nice. Although, I doubt KDE cats all their source into one blob first. GCC doesn't do *any* IPO, not even inside a translation unit. Thus, cat'ing the source code into one file wouldn't make a difference.

Re:Intel C++ Compiler 7.1 Rules

[gidds]

It's also got extremely good error messages, which [is] very important for C++ programmers.

Let's just look at that line again for a bit, shall we?

I wonder whether that says more about the cruftiness of the language, or the incompetence of most of its programmers...

[fx: enters nuclear bunker]

Re:Intel C++ Compiler 7.1 Rules

[be-fan]

Yes, template syntax is rather crufty, and requires good error messages, and sometimes even external tools (STL-Filt) to use easily. However, C++ templates do stuff that Java and C# can only dream about, so many people are willing to put up with a little extra hastle to use them.

Re:Intel C++ Compiler 7.1 Rules

[gidds]

Can only dream about? I can't speak for C# (not that I'd want to anyway), but Java's singly-rooted object tree means that it can already do all that stuff. Templates/generics would only add a little compile-time safety. And they're coming in JDK1.5, anyway.

Re:Intel C++ Compiler 7.1 Rules

[Anonymous Coward]

Except that methods aren't objects, so you have to write off most of and unless you're going to write wrappers around almost everything (probably losing optimization opportunities).

Re:Intel C++ Compiler 7.1 Rules

[be-fan]

Genericity is just the tip of the iceburg (and JDK 1.5's genericity is kinda hackish anyway). The template mechanism can be used as a complete code generator, and is the basis for lots of cool libraries like those found in the Boost, Spirit, Loki, and Phoenix libraries. In particular, the Phoenix library implements a rather decent lambda abstraction, completely through the use of templates. However, all these techniques are rather modern, so it will be awhile before compilers stop spewing 100-line template error messages at you. But the foundations of better error messages (the EDG front-end, Boost Concept Check, STLFilt) are there, so the situation seems to be getting better.

Re:Intel C++ Compiler 7.1 Rules

[Garen]

Setting the right flags for GCC isn't exactly voodoo magic. ...

You will need to often change flags to suit the application. Messing with the inlining knob is especially common for C++ code. At first it might make sense to set that particular one super-high... but when I did that, I ran into cases where GCC's memory usage would explode so much that the Linux OOM killer would kill the process! On windows it goes into swap-hell. Some more ram can fix that, but nobody should be expected to do that (and I don't think 512mb is "too low" for such a task.)

Also, I think you misread my post. I was prasing ICC's error messages, not GCC's.

Whoops, maybe so.

A quick trip to the Gentoo forums is all it takes. And you only have to choose flags once.

The Gentoo forums is one of the last places I'd ever go to learn that stuff. As someone who's already seen a zillion of those CFLAGS threads, it's obvious to me that many of them never read the manual either and throw in stuff willy nilly left and right (including redundant flags and unnecessary FP flags, ..., the whole shebang.)

I would disagree that ICC is more reliable. It's aggressive inliner has broken more code for me than GCC's.

Show me some examples. Having used them both for quite some time now, I'm inclined to think you're being dishonest.

Although, I doubt KDE cats all their source into one blob first.

Thats basically what --enable-final does. And/or Makefiles set it up so a single file #include's a ton of others. That shouldn't be necessary.

Re:Intel C++ Compiler 7.1 Rules

[RealAlaskan]

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

>Yup. But not necessarily in the reverse. ICC doesn't support all of GCC's extensions, but enough of them to build the Linux kernel.

Better than I expected. That's good.

In my original post I just wanted to point out that however wonderful Intel's compiler might be, it's completely useless for a surprisingly large subset of the machines which run Linux and the three *BSDs. Its also useless for AIX and Solaris and HPUX and TRU64 machines.

Of course, anyone who can benefit by using the Intel compiler shouldn't let its x86-specific nature stop him. Far better to allow youself to be stopped by the sort of ethical considerations which led RMS to write GCC in the first place, if you're going to let anything stop you.

Re:Intel C++ Compiler 7.1 Rules

[cant_get_a_good_nick]

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?

Code is C object compatible, not (yet) C++ object compatible (both are tracking the STD C++ ABI, not close enough for production use).

Yes but...

[Anonymous Coward]

gcc compiles code for umpteen different architectures, not just pentium and itanic. If the gcc people concentrated on one or two processors I'm sure they could get it to produce faster code too.

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.

Re:this is all well and good

[Anonymous Coward]

What we see here are Linux fundamentalists afraid of losing their religion. Easier to mod down and close your eyes, than the alternative.

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.

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.

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

[Anonymous Coward]

GNU\Linux system.

'\'
---

OH SCHEIBE, You have been using too much Windows.

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:I think the argument can be made

[Zebbers]

then rebuff that statement

Re:I think the argument can be made

[smittyoneeach]

Wasn't the intent.
It's a segmented market. The genius of Gates is that he targeted the low end, a counter-intuitive thing for the geek in the crowd.
The last thing I'd do is call myself 31337.
At some point, there will be a neurological basis for saying some people abastract well, and get off on visualizing the chain of events occuring during a complex process, whereas others couldn't give a flying French fornication about all that detail, and prefer copious eye candy.
My remark is descriptive, not condescending.

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.

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

[double_u_b]

Yes, sorry, I confused. This problem was about the order of evaluation. But I cannot understand why VC++6 has different oreder of evalutation, when in Debug mode and in Release mode. I won't be able to post the code because: - I wrote it two years ago - since it was problem prone, I changed it the days that followed - I don't work in the same company now When I arrived at SAGEM, progammers wereeven releasing Debug versions of their programs, because they didn't want to spend time on finding why release mode was not working (in fact, it was essentialy because in debug mode VC++ was initialising data, I spent a lot of time debugging that in my first month)

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

[Anonymous Coward]

GCC provide a difference way to specify this, a "inline this function or die" flag.

Similar to MSVC's __forceinline flag, no doubt.

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

[molo]

Think shared libraries and header files .. and C++.

-molo

Re:inline

[t]

For normal code, yes. For kernel code, maybe. For instance, if you're mucking with the registers, or stack or other non-normal stuff then you may need to ensure that a particular segment of code does not actually make a function call as that would be disastrous.

Re:inline

[jovlinger]

nope. I'm still confused. How could not inlining a function have a semantic effect? I mean, inlining _copies_ the function, so it should be completely transparent.

Obviously I'm wrong. How?

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

[p3d0]

There are a number of ways. Here's a scenario: suppose I write this function:

int doSomething(int theFastWay){
if(theFastWay) fastWay();
else safeSlowWay();
}

Now suppose I call it everywhere like doSomething(1). If it's inlined, the else branch is optimized away completely. There's no call to safeSlowWay. Then, suppose I don't bother to link with the library containing safeSlowWay. We're still fine (though this is arguably a bug) because the link would succeed.

If this function doesn't get inlined, there will suddenly be a reference to safeSlowWay, and you'll get a link error.

This is just one example off the top of my head.

Re:inline

[Anonymous Coward]

That's a poor example (no offense) because it's a link error, and the problem is with the makefiles, not gcc.

Maybe if the inlined code was asm and expected registers not to be dumped b a function call? That would seem like shitty code to me, though :)

Re:inline

[p3d0]

Or what if there were stack constraints (say we're executing on a sigaltstack), and the frame for the call busts the limit?

There are plenty of reasons inlining versus not inlining could make code stop working.

Re:inline

[jovlinger]

ah. Cool. So the problem is that the binary interface is computed over the optimized code, rather than the unoptimized code.

I agree: this seems like a bug (not necessarily in GCC, perhaps in the language spec). The optimized code should provide (and require) the same interface (and semantics) as the optimized code.

But then, I'm just playing armchair language designer here. C has a long history of getting by pretty well by doing what is useful, rather than "right".

Re:inline

[Fesh]

"The optimized code should provide (and require) the same interface (and semantics) as the optimized code."

I should certainly hope so... *grin*

I know what you were trying to say... Just couldn't resist.

Re:inline

[Matthew Austern]

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

If you're writing nonportable low-level code (which wouldn't be too extraordinary in a kernel), there are all sorts of ways you could detect the difference: you could use alloca, you could write code that makes assumptions about the way that stack variables are arranged in memory, you could play tricks with setjmp/longjmp, and so on.

Re:inline

[be-fan]

The problem in the kernel is such:

Say you've got a file: header.h
Say header.h looks like this: ...
int someFunction()
{ ...
} ...

Now you assume that someFunction gets inlined. If it doesn't get inlined, then each translation unit contains a copy of someFunction() and when you try to link multiple objects together, you get a redefinition error.

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.

Re:The hand written parser

[Anonymous Coward]

Awesome.

GCC's lack of precompiled headers was its only glaring flaw -- it compiled much more slowly than many commercial compilers, especially C++.

Re:The hand written parser

[jelle]

Where do you get all that info? I'm subscribed to the gcc mailing lists, but there is just too much traffic to keep up with it. Is there a secret kerneltraffic-type list out there for gcc?

Re:The hand written parser

[ahornby]

What about the compile server? Is that an alternative to PCH?

IMO the problem with PCH is that you end up with all your .cpp's dependant on all your headers - thus stuffing up any attempt at doing correct minimal includes and auto dependency tracking from make.

Re:The hand written parser

[Anonymous Coward]

Worse, the pch only supports including one pch.

Re:The hand written parser

[Matthew Austern]

Mark's recursive-descent parser isn't faster than the 3.3 yacc-based parser right now, but there also has been zero performance tuning at this point. There's reason to think that it will be faster once there has been tuning.

That is: there are a number of places where it's known that the recursive descent parser can be made faster if someone just does the work. There doesn't seem to be similar scope for improvement in the old yacc-based parser.

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

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

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 compiler, and why it should affect me as a non-developer. What am I missing here?

Re:Another one? WHY?!!!

[Gothmolly]

Read the parent post as:

I don't understand anything about C coding or systems programming, can you please let me bury my head back in the sand so that I can just run D:\setup.exe and load my gamez?!

Re:Another one? WHY?!!!

[Anonymous Coward]

uhm ... it doesn't break binary compatibility.

It's a minor release, primarily bug fixes and improvements. Would you rather wait months for your favorite show-stopper to get fixed in commercial compilers?

It may show as broken some code which is broken, but was previously allowed. Expect even more of that with 3.4

Re:Another one? WHY?!!!

[jacobm]

Yes. Read it that way, and then realize it's a totally legitimate request.

Re:Another one? WHY?!!!

[patter]

Read the parent post as:

I don't understand anything about C coding or systems programming, can you please let me bury my head back in the sand so that I can just run D:\setup.exe and load my gamez?!


That's pretty unfair, and marginally trollish as well. The question comes from a sysadmin type, that does NOT mean they're a luser.

You don't need to be C guru, or a systems programming mandarin to be forced to compile code, particularly in the open source world.

The question was simply 'Why are there so many changes that break binary compatibility?' That is a very valid question, and you need to know nothing about systems programming to explain it without being a troll.

Re:Another one? WHY?!!!

[be-fan]

You have to remember that GCC's C support is stable. The C ABI hasn't changed since around 2.95.x. It's the C++ ABI that didn't stabilize until somewhere in the 3.2.x series. The C++ standard is very complex. GCC probably supports it about 99% correctly (better than almost any other compiler except maybe Comeau C++), which means there are still lots of corner cases to fix. Also, there are lots of speed improvements to work on, and C++ compile speed needs to get fixed. So all these releases are incremental steps on the way to getting everything worked out.

Re:Another one? WHY?!!!

[cant_get_a_good_nick]

Why can't binary compatability be maintained?

It is maintained. gcc 3.2 (maybe it was in 3.1?) started to track the STDC++ ABI. I checked the release notes, I couldn't see any ABI changes in this release. Not only will all versions of g++ be able to interact, but all C++ from all vendors will be able to interact. Intel C++ 7 also is tracking the standard, they think they're close, but at this point they don't recommend mixing objects from g++. The C++ binary compatibility was growing pains until they got this stuff fixed. It's now fixed (or at least well on it's way) and your life will be much easier for it later. Think about being able to get a C++ library from someone and not having to worry what vendor's compiler compiled it. This is the price you pay now. Besides, if you're happy with 3.2.3, don't upgrade.

Re:Another one? WHY?!!!

[Anonymous Coward]

Even the C compiler is far from perfect. NetBSD still ships with a patched version of 2.95.3, because that's the last one that will compile the OS on all its platforms. When gcc development thawed awhile back, some NetBSD folks leapt in to contribute portability and standardization fixes. Their focus is 100% C, and the new compiler you're seeing reflects their effort.

I don't mean to distort the story. I don't know the relative size of their contribution, only that such problems are real, and that they'd like to use a working compiler.

Re:Another one? WHY?!!!

[Anonymous Coward]

Heh. And read THIS parent as:

"I'm a 17 year old[*] coder who can hack around any problem in C, so why should I care about stupid ideas like portability, manageability, change management, backwards compatability, or structure? I am L33T!" Sooner or later kid, you're going to have to work WITH sysadmins and even (gasp!) managers. At least if you have any intentions of being a useful member of society.

"People ask me why I feed the trolls. It's the same reason I shuffle my feet in piles of leaves."

[*]Of course, 17 mental years old could mean 37 and living in his parents' basement.

Re:Another one? WHY?!!!

[Anonymous Coward]

the reason? i guess because C++ is still a relatively recent standard w.r.t the amount of C++ code that exists. the eventual goal is for all the things the parent post mentioned, but we are not there yet!

in practice, it seems everyone's C++ code is essentially becoming "standardized" (which is great) but is in practice very difficult as the language is quite different than it was several years ago.

i know that every major release of the gcc compiler (and some in between) have helped clean up and make our code more portable. this includes a large academic research project as well as a medium sized commercial software project.

here are some points:

* C++ is a much, much more difficult language to standardize than C, Java, or even Perl due to its features.

* It's much more difficult to write a compiler for C++. it's even more difficult to write a compiler that meets the standard!

* Major New features were added after the initial C++ std. which made things even more difficult along the way

* the stdlib for c++ got standardized only recently, and this has caused issues today. many people including my self used c++ with stdc (the original C library). this made it clear that in order to maximize benefits of C++, the language needed its own standard lib. so many projects are in the process of moving over to stdc++ (at least for most of the functions if not all).

* you could be the best programmer/architect/developer in the world, but code you wrote 6 years ago in C++ wouldn't adhere to the standard because of all the changes and ambiguities!

look at the C++ Annotated Reference Manual and strousoup's Evolution of C++ book for evidence of what i've stated.

Re:Another one? WHY?!!!

[norculf]

If they're still using 2.95.3, then obviously their contribution hasn't been substantial. Indeed, the OpenBSD developers rant about this frequently, and it seems that all GCC really cares about is lunax on x86. That IS the platform that pays the salaries of the professional developers working on it for Redhat and whatnot.

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.

Re:this is all well and good

[jonadab]

Dude, that's what Emacs is for.

Still, I'm looking forward to the day when normal people don't need
C/C++ compilers anymore because everything's written in VHLLs. (The
kernel hackers and compiler/interpreter jocks will of course always
need the lower-level tools, but application developers someday won't,
just as today most of them don't need assembly stuff anymore.)

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.

Re:From the changes

[ichimunki]

RH9 has it. Gentoo's had it for quite some time. SUSE has it. Debian will, of course, have it officially in about three years, but they have it unofficially now (in fact, they have a prerelease of 3.3 in testing). I suspect it is the feature, not the compiler which is rarely used.

Re:From the changes

[dvdeug]

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

All modern Linux distributions use gcc >= 3.0. Debian uses gcc >= 3.0, and did so even in the last stable release for some platforms. Apple also uses a gcc >= 3.0. Just those groups would constitute "widespread use" by themselves, IMO.

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 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 output to html using the currently selected hilight mode.

That's missing the point

[ondelette]

A lot of code will use fstream read and write.
That's the standard way to do things. Granted,
that's not high performance programming... but
that's common programming. If 90% of C++ code out there is slowed down by at least a fixed percentage, this will have a major impact.

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

[Anonymous Coward]

But I cannot understand why VC++6 has different oreder of evalutation, when in Debug mode and in Release mode.

Probably because optimizations are turned off in debug mode, so it evaluates things in the naive order.

When I arrived at SAGEM, progammers wereeven releasing Debug versions of their programs, because they didn't want to spend time on finding why release mode was not working (in fact, it was essentialy because in debug mode VC++ was initialising data, I spent a lot of time debugging that in my first month)

The greatest IDE imaginable cannot fix poor programmers.

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

[Anonymous Coward]

vi.

This is currently my only option on a certain machine without X installed. (don't even think about emacs, satan himself could not trick me into using emacs.)

fwiw, Borland's old DOS IDE was usable, if there's something like that for unix, I would be pleased.

Err, typo...

[jonadab]

I could almost swear I typed 30%, not 85%... sorry for any confusion.
And yes, all statistics courtesy of Flagrant Estimation Incorporated.

Re:A bug in a deprecated GCC extension

[i_am_nitrogen]

That's a gcc extension? I've been using that in my code for years! Of course, all my code is compiled on gcc... Code like this:

*(unsigned int *)(voidpointer) = intval;

isn't valid C/C++? Or do you mean gcc allows something like this:

(unsigned char)(longval) = charval;

?

Don't forget patented or copyrighted optimizations

[Anonymous Coward]

They do exist - and gcc pretty much can't use them.

Re:I don't complain but

[borgheron]

Hey, don't feel bad.

This happens all the time. I have stopped submitting stories since all it seems to do is give the people who run slashdot fodder to take credit for themselves.

I believe the practice of favoring one's own select group is called nepotism. :)

GJC

Re:this is all well and good

[Lumpy]

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.



so how exactly do you do code reviews? we print it out, copies for each of us and sit in the conference room screaming at each other.

it's invaluable for a code review.

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

[Anonymous Coward]

The gcc and glibc people are the same.

Re:Ridiculous

[Anonymous Coward]

the same copyright (er, copyleft) holder (FSF), there are some developers who work on both, but many people don't.

Additionally, it's best if gcc and glibc don't depend on specific versions of each other.

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 me use... When someone misuses English, do you correct them or change the entire language to fit their mistake?

Actually, often the second. This is how natural languages evolve. On the other hand, doing this with a language like C would be silly (or alternatively you could just rename their abuse of the language C+ or something...)

Re:Ridiculous

[Anonymous Coward]

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

Looking at the "Americanized" spellings of "British" words, I would think the latter.

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:So when do we get a working debugger for g++?

[Anonymous Coward]

I know. I call it programming with rocks and sticks. :)

gcc is also the most embraced and extended C++ compiler in existance, you'd think that Microsoft wrote it. The number of completely non-standard C and C++ hacks that the compiler allows for "kernel optimization" is sickening.

Thank ghod for the Intel Linux compiler. Finally a quality, stable compiler available for Linux! (Still no debugger though)

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

[Anonymous Coward]

The whole gdb situation has had us tearing our hair out for ages. IMHO, it is a serious impediment to being productive with the gcc toolset.

Etnus (http://www.etnus.com) has a gcc debugger that is not derived from gdb. We're reasonably happy with it so far, although we haven't been banging too hard on it yet. It, BTW, the only commercial debugger for gcc that I've been able to find.

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

[WasterDave]

Nightmare, isn't it. Last time I was developing actually on Linux (a couple of months back) I had a treasured RH7.3 install with KDE. The stock GCC was a pretty mature 2.x series and hence worked well with the debugger, which in turn worked well with KDevelop.

Final builds were done by changing the path to the compiler in the makefile over to the GCC du jour. Or even icc.

Since then I've been on a bit of a portability drive and have been working on an Apple - which is OK, but a notch short of perfect.

Anyway, I'd find yourself an RH7.3 disk if I were you.

Dave

Easy

[Anonymous Coward]

Stallman controls GNU.

GNU controls GCC.

Stallman hates closed-source software.

Closed source software can only be distributed as binaries.

Binaries are a PITA when the ABI changes.

People tend to avoid things that are a PITA.

GCC frequently produces new and incompatible ABIs.

Re:Easy

[Anonymous Coward]

I can't think of any closed source software that depends on C++ object compatibility. (They've invented things like COM to work around this problem.) This problem mainly affects users of KDE.

Re:A bug in a deprecated GCC extension

[Per Abrahamsen]

> *(unsigned int *)(voidpointer) = intval;

I don't think that code has a problem, the "*" operator uses an rvalue, so you don't actually use the lvalue of the cast.

If you had written

(unsigned int *)(voidpointer) =

I believe you would have been in extension territory.

Re:this is all well and good

[Alan Shutko]

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

Emacs has been able to do that for a few years now....

I don't have a life

[Per Abrahamsen]

thus, I can follow the development list.

Re:I don't have a life

[TheRaven64]

Maybe you could post a regular precis of the list somewhere (your journal, for example) so that those of us who like to think (or at least pretend) that we do have a life could gain the benefit of your time.

I want to have a life. I don't mean I want to get a life, I mean I want to only have one. Trying to live 3 at a time leads to a shortage of sleep...

Re:this is all well and good

[be-fan]

The reason it's different from debug and release mode is that the optimizer is invoked in release mode. In debug mode, the order of evaluation is probably very straightforward and results in what you expect. In release mode, the optimizer uses the ordering flexibility between sequence points to optimize loads and stores, so the order of evaluation probably becomes different.

That said, VC++ is a hideously broken C++ compiler. I have nothing good to say about it.

OS X binary compatability

[Rubel]

3.2 broke binary compatability with 3.1, right? and 3.1 (modified) is what is used in OS X 10.2. Does this mean Apple will have to do a lot of munging to use 3.3?

Re:OS X binary compatability

[dhazeghi]

Yes. And if you're brave, you can check it out of cvs (Apple's version). Bottom line is that if you're an OS vendor, you can afford to those sort of things.

KDevelop is not just as good.

[EnglishTim]

As far as I can tell, there is nothing as good as Visual Studio for Linux. Naturally, this was a huge disappointment to me when we migrated from NT to Linux at work.

Don't get me wrong - KDevelop is a brave attempt, and coming along, but it just doesn't match Visual Studio. The most incredibly irritating thing about it is the diabolical project management. I had to hack my copy just to make it slightly useful at all, and eventually I just gave up on it. Now I use jedit, handmade makefiles and kdbg. I still miss MSDEV, though.

Fairly soon I'll try KDevelop 3 again to see how it's come along, but if you're used to Visual Studio, you will be disappointed.

I'm still trying to find a nice GUI-driven debugger, as kdbg seems rather flaky.

Re:KDevelop is not just as good.

[Anonymous Coward]

If you're writing linux code at work and miss Visual Studio then you definetely need to try Visual Slickedit. It has code-completion(intellisense) for c/c++,java,c#(mono) and a whole bunch of other nifty features that ex-Visual Studio users will love.

Re:KDevelop is not just as good.

[EnglishTim]

I've just downloaded it - it seems nice!

It's a shame though that few editors for Linux have worked out the One True Behaviour For Ctrl-Tab yet, whereby rather than going through all the files in the same order every time, it orders them in order of how recently viewed they were. It makes it much easier to switch between 2-3 source files that way.

Re:KDevelop is not just as good.

[zenyu]

I'm still trying to find a nice GUI-driven debugger, as kdbg seems rather flaky.

Try the gdb tcl/tk debugger it uses the new binary interface to the debugger so it shouldn't be flacky in the same way any debugger that parses the gdb text output can be. You need recent tcl/tk, but otherwise is not very dependency ridden. I'd like to make a few kdbg points though:

1/One guy is doing most of the development
2/He's very receptive to applying patches
3/The code is actually pretty clean. I was able to patch something that annoyed me in an afternoon. He applied most of it within a week, and the rest after I spent another afternoon cleaning it up a little.
4/Try the kdb-devel out of cvs with gdb 5.3, I haven't had any problems, and it's a bit more polished than 1.2.7. I do compile the debug versions without threading most of the time, but that isn't much of a restriction for me.

Re:KDevelop is not just as good.

[AvantLegion]

The most incredibly irritating thing about it is the diabolical project management.

LOL. Good, it's not just me. What a hassle I had just trying to import some outside existing source files to an already-created project!

I have high hopes for KDevelop - outside of the irritations and hassles (WHY CAN'T I RESIZE THIS DAMN WINDOW FRAME??), and the instability of the Gideon alphas (which, as of the latest alpha release, actually seems to be almost fully fixed), it's quite nice.

KDE is not dominated by binary file processing

[Per Abrahamsen]

so it shouldn't be affected by this particular regression.

Re:KDE is not dominated by binary file processing

[ondelette]

It also impacts text file processing (see full description of the bug report).

Ugh... project management

[EnglishTim]

As far as I can tell, Anjuta suffers from the same problem as KDevelop - very inflexible automake-based project management. Otherwise I'd be up for using it, but the project management stuff is such a pain in the ass.

Re:Ugh... project management

[Anonymous Coward]

I hear ya. KDevelop is unbelieveable for this. On my PIII-600 it took like 10 minutes to create an empty "hello world" console C program using KDevelop. At the time I tried it, I was looking around for a simple but useable IDE for my wife to do her basic coding with under Linux. I'm still looking...

Re:this is all well and good

[Evil Grinn]

Still, I'm looking forward to the day when normal people don't need
C/C++ compilers anymore because everything's written in VHLLs

Do Java and C# qualify as "VHLL" to you? If so then you may get your wish. However, you probably meant true scripting languages.

Almost every user application except for cutting edge games could be written in Perl/tk or Python or XUL or something. Unfortunately, the ability to do this has existed for years if people aren't using it now I don't predict that they'll start.

(Aside: Back when Java first came out, I remember thinking that it seemed really ass-backwards to try to force the old "compiler" paradigm back into a world (the web) where scripting had already become ubiquitous. Obviously I underestimated the power of the "we're better than you script idiots" elite programmer mindset (And I mean elite, not l33t. The kind of people I'm talking about tend to spell things correctly (and I'm saying all of this as a former scripter who has managed to become "one of them" for the money (HDANCN?)))).

I am now in serious danger of getting modded off-topic.

make -j

[Per Abrahamsen]

It is pretty easy to do with a parallel make (GNU make is fine) and a wrapper script that rsh gcc to apropriate machines. I did it back in school when I had access to lots of Unix machines.

I don't know if there is any projects to formalize this, but in these SourceForge days there most likely is.

Re:make -j

[Anonymous Coward]

> I did it back in school when I had
> access to lots of Unix machines.

Some people are just so lucky - the only
thing I had access to in school was a slide rule.

Re:make -j

[MerlynEmrys67]

Lets see, go look at the distcc project samba.org a fast, free distributed C and C++ compiler. It is even more fun when you patch in ccache as well ( I'll let you find that one on the samba site )

Nothing like having a huge build complete much faster. Turns out that the limit on speed is how fast the machine doing the preprocessing is though.

Choices, Intel C/Fortran, GCC...

[Bold Marauder]

I clicked on one of the intel ads last night and was debating wether or not to download the 'unsupported' linux version of intel C & Fortran. Mostly just to play around with.

I'm wondering if anyone here has played with intel (esp under Debian) C and has any comments on it versus GCC.

Also [on a fortran note] if it would be worth getting intel fortran for the sake of fortran 95 support, or should I stick w/ the ubiquitous [sp?] gcc/fortran 77 which runs everywhere?

Opinions, anyone?

Re:Choices, Intel C/Fortran, GCC...

[Aardpig]

At the moment, I wouldn't bother switching to the Intel F95 compiler. Although it is a very good compiler (in terms of efficient code generation), it lags behind other compilers in terms of features supported. By this, I mean the TR-15580 and TR-15581 extensions to the FORTRAN 95 language, which most vendors support, and which are linguistically-important extensions which fix mistakes made in the original FORTRAN 90 language spec. Both extensions are endorsed by J3 (the ISO body which publishes FORTRAN standards) and WG5 (the working group which develops new FORTRAN standars -- at the moment, they are working on FORTRAN 2000).

I am eaglerly awaiting the completion of g95, the GNU gcc-based frontend for FORTRAN 95. At the moment, I use a combination of Intel, Lahey and NAG compilers for my FORTRAN 95 needs, but projects I am programming are specifically geared towards what g95 will support. If you want to program with the future in mind, sure, switch to the Intel F95 compiler; but have in mind that the FORTRAN language itself is advancing, and it might be better to (temporarily) spend some cash and get a compiler which is moving with the the language.

Re:Choices, Intel C/Fortran, GCC...

[Anonymous Coward]

You could certainly get Intel Fortran for the sake
of Fortran 95 support. g95 is still at least
a year and a half away ...

Toon Moene (g77 maintainer).

Re:A bug in a deprecated GCC extension

[Anonymous Coward]

GCC alreday has precompiled headers.

look here

Hmph

[magi]

About every GCC release breaks most of the software written for previous version, especially for C++, as it's standard keeps "refining" constantly, as does GCC's interpretation of it. Not to mention the extensions.

Right now I'm busy changing all "#include" to "#include", "friend Foo" to "friend class Foo", and adding "using namespace std" everywhere. What next?

Re:Hmph

[magi]

Right now I'm busy changing all "#include" to "#include"

Umh, intended to say: changing "#include <iostream.h>" to #include <iostream>". Damn markup.

Re:Hmph

[Anonymous Coward]

All of these were changed from 2.95 -> 3.x, not 3.2 -> 3.3. And they were wrong then...

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

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

[Anonymous Coward]

your points are true, but i think this is more about the reliance that programmers have on the compiler to help produce good code (in certain respects).

g++ has taken time tracking the C++ std (because writing a solid, portable, standard C++ compiler is very difficult).

so, namespaces were around since 1995, but when was it that it was actually implemented by g++ ? relatively recently. so even if you wanted to adhere to using namespaces early on, you may not have had the ability to do so. and this, plus other factors (keeping compatibility with other compilers, etc.) made it difficult to "catch the hell up"

(version 2.7.2, v.2.8 started to recognize "using namespace" but didn't fully support it)

i hope no one takes the work on g++ for granted, as its a important project for computer science in general, IMHO.

Re:Hmph

[The Bungi]

Now I understand what Bjarne Stroustrup wrote, when he described /. as "ignorant, and proud of it."

If you think it's easy, why don't you give it a try? [...] If you don't like it, you should demand your money back.

Now I understand why a friend of mine calls /. "too arrogant for its own good".

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

[Anonymous Coward]

Why not just make a link from iostream to iostream.h?

Re:Hmph

[be-fan]

Actually, the last change was Technical Corrigendum 1 published in 2001. However, it was mostly minor defect fixes, so it's not really an excuse. I think they major reason the original parent is bitching is that he's used to Visual C++ 6.x, which just likes to pretend that the C++ standard hasn't changed since 1995 :)

Re:Hmph

[Anonymous Coward]

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

I think we can hardly blame a lot of people who have been (and are still) stuck with something like MSVC6. For that Microsoft is to blame, and I think they've really harmed using C++ because their compiler is on such an important platform that it can hold people hostage and make itself a least-common-denominator.

Some of the blame I'd also put on the C++ standardization process. They simply should have taken implementation difficulty into account, which has also undermined compatibility and made making a C++ compiler pretty much a large-scale operation. Thus lowering the number of implementations and diversity of the compiler "ecosystem."

Even though the standard has been out since 1998, GCC hasn't implemented it correctly. How are people supposed to "catch the hell up" to a moving target? They simply don't, and stick to a particular toolchain for quite awhile and migrate in batch-mode fashion.

Re:Hmph

[devphil]

I'm not counting TC1 as part of the language until the public actually has access to it (for a fee or otherwise). It's still only available to committee members at present.

Re:Hmph

[devphil]

In fairness, I should point out that I don't know how to do most of this either. But I don't complain about volunteer work not living up to my expectations...

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:I'm still amazed

[Anonymous Coward]

GCC gals? That would be a nerds total fantasy, they simply don't exist! :o)

Re:I'm still amazed

[TheRaven64]

Well, a true BSD advocate would argue that anything GPL'ed isn't truely free...

Mind you, then they'd be left without a working compiler...

Guilty as charged. I go suicide now [nt]

[gazbo]

I SAID ENN-GODDAMNED-TEE

GCC 3.3 is binary compatible with the 3.2 series

[Per Abrahamsen]

And why release it?

It fixes lots of bugs, obviously people who have been bitten by these bugs will want them fixed as soon as possible. And those who need the new feautures tend to need them yesterday.

All these people are developers. I do not see any reason for non-developers to care, just use the compiler bundled with your OS.

BTW the last full release was 3.1, quite some time ago. All the intermediate releases (including 3.2) have been bug fix releases with no new features.

Still buggy for Dreamcast

[Forkenhoppen]

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

Re:Incredibuild?

[Anonymous Coward]

You mean, something like http://distcc.samba.org/ ?!

If you care about performance...

[Per Abrahamsen]

install both and measure. My application, a numerical simulation written in C++, was 5% slower when compiled with icc. The better benchmarks show the same thing, icc is faster for some tasks and slower for others, but expect for very specialized tasks they tend to be in the same ballpark for real applications.

Re:If you care about performance...

[Anonymous Coward]

How much effort did you spend trying out optimization strategies with the intel compilers? I found that the baseline was comparable to, or a bit slower then GCC, but the extensive optimization options made a big difference.

In particular, the profile guided optimization but my app a few percent alone.

Re:If you care about performance...

[Per Abrahamsen]

None, really. I used -O2/arch/cpu/fast-math flags on gcc, these are default on icc (it got them anyway).

Both icc and gcc have profile based optimization, I haven't experimented with either.

One would obviously need two datasets, one for generating the profile, and another for testing performance.

Re:If you care about performance...

[Anonymous Coward]

FWIW, here's a summary of my optimization benchmarking. percentages are WRT the best GCC build I could get. All are an average of 3 runs.

Actually, it looks like I mis-remembered ... even my baseline performance with icc was substantially better then gcc.

-O2 14.94%
-O3 11.31%
-O3 -ipo 15.74%
-O3 -xK -ipo 15.77%
-O3 -xK -tpp6 -ipo 13.34%
-O3 -xK -ipo libimf 16.25%
-O3 -xK -ipo intel libs 13.79%
-O3 -xK -ipo libimf profiled 20.20%
-O2 -xK -ipo libimf profiled 19.95%

I didn't know that GCC had profile-guided optimization?

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:A bug in a deprecated GCC extension

[i_am_nitrogen]

The patch in the original bug post looks like this:


- ConfigItem** ip = &(ConfigItem*)menu->data;
+ ConfigItem* i=(ConfigItem*)menu->data;
+ ConfigItem** ip =


So I guess you're right; the & operator would use an lvalue. One could code *(void*)5, but not &(void*)5.

The way I would've coded that particular code in one line is:
ConfigItem** ip = (ConfigItem**)&(menu->data); /* Can't remember if & or -> is evaluated first, so I added () */

Or the (unsigned int *) example case you gave as:

voidpointer = (void *)uintpointer;

So, I really don't see this extension as anything more than a potential way for increasing gratuitous obfuscation for the purpose of the obfuscated C contest.

Re:A bug in a deprecated GCC extension

[Anonymous Coward]

Or more accurately *5 vs. &5.

Waiting for the handmedown from Apple

[Soong]

macosx% gcc --version
gcc (GCC) 3.1 20020420 (prerelease)

Not going to go grab the latest GCC because I wouldn't count on it to work with ObjC, MachO, and whatever else Apple may still be patching in.

Re:this is all well and good

[Anonymous Coward]

it's easier than anything microsoft has ever written in their IDE

SlickEdit is not a Microsoft product.

Re:this is all well and good

[Anonymous Coward]

Even if it were true, your argument undermines itself. If Linux really required all those extra developers for that much less net production, it truly would be "developer hostile".

Re:this is all well and good

[Anonymous Coward]

The parent post never said it was.

please re-read it again... I never read anywhere that said "...slick edit, a microsoft product,...."

Assumption is the mother of all screw-ups.

Re:this is all well and good

[dead_penguin]

Fair enough; we do our reviews a little differently.

We don't do very many "comprehensive" reviews with several people going over a complete feature. Instead, every single line of code that gets checked into source control MUST be reviewed by at least one other person; preferably someone familiar enough with the code to be able to see what it impacts.

For smaller changes to existing code, a diff of the "before" and "after" code is generally enough to see what was done. Bigger changes usually end up being reviewed by more than one person, just not all at once. All of this is done on the computer.

It's not perfect, but this works quite well for our situation-- and it saves us some paper as a side-effect.

Re:this is all well and good

[Lumpy]

ahhhh, makes sense... we have many old-hairs here that require that we kill a forest weekly for every little thing.

hell they still require that we fill out time sheets online and PRINT THEM to put in their inbox.

I like your way better.

Re:this is all well and good

[yamla]

The Visual C++ compiler included in Visual Studio .NET 2003 is a vast improvement over previous versions. I believe it even compiles the loki library now. :)

Seriously, what you say is correct for Visual C++ 6 (which was god-awful) and for Visual C++ .NET 2002 (which was only slightly better) but I think you probably haven't tried out the newest one yet.

Re:this is all well and good

[Anonymous Coward]

so you haven't touched winblows (sic) in over a decade (eg, before 1993), and yet you're qualified to tell us what's wrong with Visual Studio?

Either you're full of shit, or ... you're full of shit.

But this is slashdot. Go recompile your kernel or something, ass clown.

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

question: will it take quotes in a macro

[Rob Y.]

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

This quote below makes me hopeful.

I've had trouble with this macro in gcc:
#define TRIGGER_PUSHBUTTON(c)
((PUSHBUTTON16) | 'c')

gcc doesn't like having the macro add the quotes around the character argument. Only works if you to leave the quotes out of the macro definition and require them in the macro argument.

But I have a lot of code written on AIX that uses this macro (and others like it). Porting to linux requires 'fixing' all the occurrances.

Anybody know if this applies?

Re:question: will it take quotes in a macro

[Anonymous Coward]

Try this:
#define foo(c) *(##c)

That converts it to a string and derefs it. However, during constant propogation, it will be converted back to a character literal. Ugly, but it works.

Re:question: will it take quotes in a macro

[Anonymous Coward]

Stringify is #c
## is the concatenation operator.

Re:this is all well and good

[Anonymous Coward]

However, if the modification date/time between the source and object file are the same, it won't rebuild the object file. Extfs use a one-minute granularity, so if the source code is updated within a minute of the last compile. it may go unnoticed. Linux refuses to fix the extfs problems (due to backward compatability issues). I reccommend using UFS or XFS.

Re:this is all well and good

[Anonymous Coward]

That is not a compiler or IDE problem. That is what to be expected from an unexperienced developer.

To rely on certain compiler quirks just spell - never done that, never been there.

BTW - Microsoft VC produces extremely good code, much better than Intel C++ and a lot, LOT, better than GCC 3.x. Perhaps not for the Itanium or other vaporware products but for straight c/c++ apps there is yet no one to beat MSVC++).

Just try a dhrystone or whatever. On Windows and the correct options it just can't be beaten. At least not as of today (yes, I've spoken to IBM and their compiler team).

(I am a pro-Linux user - I wrote several parts of the bootloader for Mac68K but the nonsense about MSVC being a bad compiler is just too much.

Whatever they do, they are pretty good at understanding the x86).

I had the opportunity to spend a couple of months evaluating compilers. The result? Don't kill me now - but MSVC is a pretty good averall compiler ...

Or whatever ...

gothmolly sez:

[Bold Marauder]

d00d! YU0=t3h $u}{0R, I=31337 ]-[@}{0R. 101101101101!!! -g0thm011y

GCC3 preprcessor problem

[Mongoose]

I've noticed in gcc 3.x that #include "header.h" looks for system header matches *before local scoped headers.

Is it just me or is that wrong and annoying?

I've had to distribute shell scripts to swap out filenames for compilation ( which wouldn't be fun to do by hand, trust me ) everytime gcc3 compiles the code base.

I don't track gcc3.x, but has this been fixed or is it intentional to cause confilcts you can't possibly predict on another system?

Here's a problem you could predict as an example:

#include "endian.h"

Then lots of odd compile errors ensue confusing the user. Also #include seemly includes -- wtf is up with that? Are these people using old/bad gcc3.x builds?

Re:GCC3 preprcessor problem

[Mongoose]

I like how slashcode ate my examples all to hell. I got so used to other boards translating the symbols to HTML for me. =(

#include "endian.h"
That actually includes <endian.h>

the last example was:

#include <dir/math.h>
Does #include <math.h>

Re:GCC3 preprcessor problem

[Anonymous Coward]

I've had a weird preprocessor problem too. Basically, it seems to be selecting the wrong header, or one is getting an incorrectly high preference, like:

#include <foo.h>
...
And somewhere else in the program, I have an:

#include "foo.h"
...
which is a local header, and all hell breaks loose. For the life of me I can't figure out why, because I can only reproduce it on some systems and not others - with the same compiler version! ugh.

Re:this is all well and good

[GlassHeart]

since it was problem prone, I changed it the days that followed

Now that you understand the problem, I strongly suggest you acquire an authoritative reference for C or C++, whichever you are using. If you can read the ISO standard, that's obviously the best resource. Electronic copies are available for about $20, I think.

What you did was rely on something the language never guaranteed. C defines a concept called a sequence point (mainly the ';' at the end of a statement, but there are other sequence points), at which point all previous expressions would have been fully evaluated. Between two sequence points, however, it guarantees nothing. So, this:

a[i] = i++;

is undefined, because since '=' is not a sequence point, you don't know which value of 'i' will be used to get a[i]. In fact, as you've found out, it can differ between debug and release builds. On the other hand, this:

a[i] = i;
i++;

is valid C code, because ';' is a sequence point, and 'i' is not both modified and accessed between two sequence points. C++ basically inherits all of this from C. Sequence points in C is a level of understanding that should give you chills thinking back at every line of code you've ever written.

When I arrived at SAGEM, progammers wereeven releasing Debug versions of their programs, because they didn't want to spend time on finding why release mode was not working

That's just sloppy. A difference in behavior between debug and release builds can be an indicator of major bugs that are merely better hidden by the debug version. The bug may still surface when the program is subjected to real world loads, or some unexpected input. It's possible that a compiler bug causes the release build to be broken, and so you ship the debug build, but not investigating is plainly irresponsible.

gnu enterprise. free.

[zymano]

http://www.gnuenterprise.org/project/what.html

(OT) Proportional fields in HTML forms

[yerricde]

Why give a Subject: line textbox that won't let me use all of it?

Because your browser is using a proportional font. Would you want the box to resize, triggering a reflow, every time you type a character? Even with the user-code performance improvements of the GCC 3.x series, the median user would still get lag.

Re:(OT) Proportional fields in HTML forms

[devphil]

Ah. Good point. My mind still thinks monospace font for some reason. Thanks!

Re:I don't complain but

[Anonymous Coward]

Hear, hear! But not too worry - it's the same everywhere. /. is still a good information source despite its cliqueishness. And quite often I find more information in the comments - where anyone is free to post - than in the lead story, anyway.

At run time?

[yerricde]

No where does it say that a "real" i686 must have cmov, the compiler should check for cmov before using it.

The cmov instruction is used in tight loops. Would you really want to branch around cmov at run time based on the cpuid? It'd completely defeat the purpose of cmov. I say define "i686" as an ia-32 CPU with cmov and leave it at that.

Re:this is all well and good

[stephenb]

There is something, it's called RHIDE. It's actually quite slick, I used to use it for programming apps using djgpp. I haven't used it in quite a while, but it looks like it's still quite active, with the latest release being Feb. of this year.

Re:this is all well and good

[shredwheat]

"Speed optimization has _never_ in my 5 years of using VC++ produced bad code..."

You make a fairly bold claim that the VC optimizer does not mangle code, especially after proving your limited experience. For a simple example go see the SMPEG mpeg decoder. The core audio decoding functions must be compiled with VC's global optimizations off or it will bork bork bork.

Re:this is all well and good

[Anonymous Coward]

I wrote several VB Scripts that wrote out comments in the code.

Getting paid by the line, were we?

Seriously, I'd think that any comment which could be scripted probably is extraneous, as in:

/*Increment i*/
i++

Comments should tell the things which aren't in the code.

Or did you mean that you wrote a script which placed the ``/*'' and the ``*/'' and placed your cursor between them? Just like emacs has done for so many years?

Re:this is all well and good

[AT]

Extfs use a one-minute granularity

Also false. Ext2fs uses has a one second granularity, like most traditional Unix filesystems. This is easily demostratable with "ls -l -time-style=full-iso". While this is still a fairly coarse measurement, I've never seen a problem in practice.

Re:this is all well and good

[Horny Smurf]

emacs can't print color on my bw laser printer!

Pentium4 bug

[PimpNinjaWannaBee]

Anyone known if this release fixes the march=pentium4 bug that exists in 3.2.x?

Check your own boxen with:

# python -c 'int(10000.3);'

Re:Pentium4 bug

[dhazeghi]

Well, it bootstraps with -march=pentium4, and glibc compiles and runs fine with it, so P4 support certainly has improved. Exactly how good is it? If only I had a P4 to tell...

my bad: 3-5 times, not 3-5%

[ondelette]

I'm the one who filled the bug report, so I should
have known better.

I don't see why anyone would accept the current libc++ for anything else but a beta or even an alpha release.

It probably doesn't get noticed so much because fstream isn't used that much.

For something like koffice or kmail, assuming it uses fstream, I suspect that one would notice the difference.

Re:this is all well and good

[Anonymous Coward]

Still playing catch up to vim, emacs, etc. ;-)

Teh GCC-3.3 Fails It!!

[Anonymous Coward]

Just kidding. Eat my shorts.

Re:this is all well and good

[Anonymous Coward]

I most especially love the "sure its hard to use at first ,but eventually you get used to it and hey LOOK you can write scripts in visual basic to automate your comments!" part. I guess he was just another graduate of the "Free, please take one!" school of Microsoft computer certification.

Our experience not so good

[spitzak]

With tiny test C programs the Intel compiler produced stunning results, like sometimes 3 times faster than GCC (this was slightly older gcc, perhaps 2.9.0 or so). Unfortunately as soon as we applied it to our real C++ programs we found the results to run at exactly the same speed. My guess is the stuff was too complicated for it to use any of it's optimizations.

The Intel compiler on Windows is about 30% faster than VC++ (version 6, we have not tried the .net version yet) with these same C++ programs, and the result is perhaps 4% faster than the GCC 2.9.6 Linux version (the program is entirely compute-bound, so this is not an OS difference). So far we have not seen even this 4% improvement in the Linux Intel compiler, which leads me to believe they have not put as much work into it as they did for the Windows one.

Re:Our experience not so good

[HuguesT]

Hi Bill!,

Just to confirm I have the exact same experience. After a lot of effort and time spent, the recompile of our complete image analysis library (100% pure C) with the most aggressive optimizations we could find in the Intel documentation yielded a 5% improvement in speed in the final product over gcc-2.96. Not worth the effort.

However the recompilation effort with icc did point out some ANSI incorrectness and some outright bugs, so it was not completely wasted.

Re:Intel C++ Compiler 7.1 Rules because of OpenMP

[ron_ivi]

Intel's compiler rules on multiple processor systems (including fake-multiprocessor Hyperthreading systems) because of cool compiler-enabled parallel application support via OpenMP.

http://www.openmp.org/

With Dual CPU systems and Hyperthreading, you can get near 2X advantages on quite a few algorithms.

I haven't kept up with Gnu's OpenMP stuff. I guess this is one such project. http://savannah.nongnu.org/projects/gomp/

A question about gcc cpu Optimization?

[grolschie]

With gcc these days is it safe to compile my linux kernel and other stuff optimized for a particular cpu (eg: Athlon K7)? I read somewhere not to do this for the kernel? Grunt, we wants! :-)

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

What you need to do...

[Jimithing DMB]

... is find something Better Than Ezra.

Okay, it's a groaner.

Upgrading from 2.96 to 3.3 (or 3.2) gotchas?

[Alinraz]

I do development work using gcc on my local Mandrake machine with 3.2. I tried to compile one of my projects on our server which uses gcc 2.96 and it fails (3.2 follows the ANSI C++ standard, 2.96 is old-style) due to the older C++ libs. I want to upgrade our server to gcc 3.2, but since we've got other projects that work fine under 2.96, we are afraid of breaking the other projects (especially since we are close to release). Does anyone know of any gotchas? Can I just download, compile, and install 3.3 (or 3.2)? Will I also need to download, compile and install a new glibc? Can I install gcc 3.3 and not change my glibc version? Thanks, - Steve

Re:Upgrading from 2.96 to 3.3 (or 3.2) gotchas?

[elflord]

I do development work using gcc on my local Mandrake machine with 3.2.

Good.

I tried to compile one of my projects on our server which uses gcc 2.96 and it fails (3.2 follows the ANSI C++ standard, 2.96 is old-style) due to the older C++ libs. I want to upgrade our server to gcc 3.2, but since we've got other projects that work fine under 2.96, we are afraid of breaking the other projects (especially since we are close to release). Does anyone know of any gotchas?

The older compilers are less strict, so you might need to clean up some compliance issues with your code if you have any. Alternatively, you could just install the new compiler in a different directory (/usr/gcc-3.3) and then place symbolic links to the required runtime libraries in /usr/lib. Then when you compile, place -L/usr/gcc-3.3/lib in the linker line. You don't need to install a new glibc to use a different compiler.

depends a lot on your code

[Trepidity]

I've seen numbers anywhere from 5%-200% penalty, though I don't have any references at the moment. It really depends on the app and where your main execution time lies. If you do a lot of tight loops over arrays, it's going to give you a significant performance hit. If you don't, it won't. So it's probably going to slow down your MP3 encoder a lot, but probably won't result in a noticeable slowdown for most userland apps. For most apps, which are I/O- rather than CPU-bound anyway, it's a good idea for security reasons. Same reason strncpy() is recommended over strcpy(), despite the performance hit due to bounds checking (in fact, strncpy() is just a special-case example of bounds checking).

Re:this is all well and good

[be-fan]

Ack. I should have qualified it. I meant the earlier VS compilers. I have heard that VS.NET 2003 is quite complient.

Re:this is all well and good

[Anonymous Coward]

Visual Studio will be even nicer to use if you installed the Visual Assist add-in.

Re:Intel C++ Compiler 7.1 Rules only on Intel CPUs

[cjellibebi]

I heard a rumour somewhere that if ICC detects an AMD CPU, it either compiles the code to slower code (if it's compiling on an AMD CPU), or it builds EXE's that detect if it's running on an Intel or AMD and if running on an AMD, the EXE runs a bit slower. This was not true for early versions of ICC but at a certain version, they added this detection. Anyone know anything more about this?

Re:this is all well and good

[Anonymous Coward]

A data point: we recently converted a big chunck of C code to Python, for flexibility reasons. We took a 5x performance hit on that code, and that's a pretty good result.

If I could replace our thousands lines of Python with a compiled "VHLL" language (Scheme, Lisp, OCaml, Dylan), I'd probably get a 10x performance gain on that part of the code (which can account for 80% of our runtime).

Sadly we'd still need an interpreter then (for user scripts) and I don't see our users providing Scheme/Lisp/OCaml scripts. As far as Dylan goes, Gwydion Dylan doesn't support the C-FFI yet and doesn't have a way to merge the interpreter (Mindy) with the compiled code (d2c / cc).

So, no, most applications can't be rewritten in Python/Ruby without causing an enormous performance loss. I love Python but it's not there when it comes to performance.

Re:this is all well and good

[TrancePhreak]

The answer is however TRUE. As this is the make that comes with a certain development kit and is quite outdated.

Re:this is all well and good

[jonadab]

> Do Java and C# qualify as "VHLL" to you?

No.

A VHLL can be compiled, but it has to allow the programmer to take
certain things for granted, such as memory management. In a true
VHLL, it is not possible to dereference an invalid pointer, not
possible to overrun a buffer, not possible to jump to an invalid
address, ...

It is still possible to shoot yourself in the foot, of course,
but you have to do something visibly dangerous, like shell out
to a system call with untrusted data -- and compiler warnings
can alert you to all the places you do this, so you can check
them. You can mess up your checks, of course, or just not
bother to be careful, but it's better than a traditional HLL.

> Almost every user application except for cutting edge games
> could be written in Perl/tk or Python or XUL or something.
> Unfortunately, the ability to do this has existed for years
> if people aren't using it now I don't predict that they'll
> start.

They are starting; it's just gradual. Also, you (the user)
don't always _know_ an app is written in a VHLL. I didn't know
printerdrake was written in Perl until I needed to debug a
problem I was having. (The problem was not with printerdrake
as such, just a printer that wasn't supported, and I had the
manufacturer's PPD and was hoping to figure out how to make it
work.) I was able to trace the issue as far as foomatic, but
I ran into a binary (which was probably written in C) and gave
up then.

There's a performance penalty for using current versions of
Perl or Python instead of C. But hardware is getting better,
making that performance penalty less relevant, and the VHLLs
are getting better too. Perl6 is going to be *vastly* better
to work in than Perl5, for example. Personally, I would be
happy to trade 50% more CPU cycles and 50% more RAM for apps
developed in VHLLs, for an assortment of reasons, most notably
because such apps would be much easier to maintain.

It will come, in time. They said assembly language would never
pass out of vogue, because you got so much better performance
with it. Sure, it took longer to write programs, but you got
programs that performed better... C and its kin are basically
a case of that same thing.

What's odd is that lisp doesn't seem to be in this category
(with C I mean), even though it's quite old as HLLs go. I don't
think I'd consider common lisp to be a VHLL either, though. I'm
not sure where to categorise lisp.

Re:this is all well and good

[jonadab]

> If Linux really required all those extra developers for that much
> less net production

How do you calculate net production?

Re:this is all well and good

[HuguesT]

> why is it that no programmer's editor cannot
> print the highlighting in color?

As everything else, Emacs does it just fine.

Vouching for Anjuta

[AvantLegion]

I don't know why Anjuta doesn't get talked about more. I like KDevelop, but it's awful flakey sometimes (both 2.1.5 and the 3.0 alphas - at least the latest alpha no longer crashes on me). Anjuta is pretty solid, not particularly flashy, but well laid-out and stable.

Re:this is all well and good

[Anonymous Coward]

To catch UP with vim and emacs?

Re:this is all well and good

[Anonymous Coward]

Actually, the company I worked for at the time wanted function header comments like:

/**(astrixes were out further but /. didn't like it)
FUNCTION: Abc(int x)
PURPOSE: what ever it does
***/

It got annoying having to do that all the time. So I wrote a couple scripts to do this for me. The main one I used all the time was easy to use. I simply highlighted the name and arguments, and pressed a couple of keys and everything was written in the code and the cursor was left write after "Purpose:" so I could type in the purpose of the function.

You're right about the example code you gave for scripting, but there are other purposes. I also had scripts to remove the lines deleted. Visual Studio doesn't actually delete lines in the .cpp file. It comments them out using something like "//DEL" (I don't remember if that's the acual comment). I have several others too. Scripting can be a great and powerful tool.
Emacs is far to complicated. The only thing it doesn't do is emulate the kitchen sink.

Re:this is all well and good

[rastos1]

So, this:

a[i] = i++;

is undefined, because since '=' is not a sequence point, you don't know which value of 'i' will be used to get a[i].

Hm.Let's say i has value 3. = has associativity right to left. So the expression on RHS should be evaluated first: i gets incremented, RHS gets value of 3. Then the LHS is evaluated to a[4]. Finally RHS is assigned to LHS: a[4] get's value of 3.
However my compilers disagree with each other. Can someone enlighten me?

Re:this is all well and good

[GlassHeart]

Hm.Let's say i has value 3. = has associativity right to left. So the expression on RHS should be evaluated first:

Please read my post again, or find yourself an authoritative reference in C. In C, the order of evaluation is essentially undefined, except at sequence points, where all previous expressions and side effects are fully evaluated. Accessing and modifying an object separately between two sequence points is undefined behavior.

It has nothing to do with associativity, which only means anything if your C statement doesn't invoke undefined behavior.

However my compilers disagree with each other.

Not only that, your compiler may disagree with itself depending on whether optimizations are enabled or not. This is because you invoked undefined behavior, for which no particular result can be expected.

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 header files will be included.

5) Because no file include all.h directly, it will not figure in the autmatic generated dependencies, and you should not add it manually. Thus, any source file will be recompiled only when the header files it includes directly are changed.

This solves the "only one include file" problem AC mentions, and means the source and include files are identical to the non-PCH version.

The danger is that there might creep in hidden dependencies, i.e. source files that does not include all the headers they should, yet compile due to the pre-include of all.h. So you will have to make an occational build without PCH.

Re:this is all well and good

[TrancePhreak]

With comments like this, I'm surprised it compiles at all. Please find some non-hacked together code to put me on trial by.
"Added a hack to seek past raw video data in a system stream"