Comparing Linux C and C++ Compilers 379
ChaoticCoyote writes "I've posted a comparison of recent GCC versions (3.3, 3.4, and the coming 4.0) with Intel C++ 8.1, including several benchmarks and "state-of-the-product" reviews. The new article replaces an older piece I published in late 2002. This
new comparison marks what I hope will be an ongoing series that tracks the quality of Linux compilers."
gcc! (Score:4, Insightful)
FP?
Moll.
Re:gcc! (Score:5, Informative)
ProPolice stack smashing protection patches for one. (and many others besides.)
And cross-platform compatability. I can compile for targets. Like working on embedded products.
Oh, and Distcc for realy big projects to get compiled quickly using easy to setup clusters.
It's "correctness" is pretty high up their, too.
Remember, for Unix:
compatability, portability, flexibility > speed.
If all you ever have to worry about is x86, then it's not that big of a problem, but for anything else there is no comparision to GCC that I am aware of.
That it having it free software rocks.
Re:gcc! (Score:2)
Sorry but... ProPolice sucks.
Nobody cares about stack smashing protection anymore these days. Besides, GCC 4.0 has libmudflap and -fmudflap for C and C++. While this isn't exactly the same as stack smashing protection, it is still very effective and much more efficient.
It's not entirely without reason that IBM still hasn't posted ProPolice for inclusion in the FSF GCC mainline. The patch against SUSE's hammer branch has been floating around literally for years, but they know really only very few peopl
Re:gcc! (Score:3, Interesting)
I googled a bit to take a look at this mudflap thing. While it looks interesting, the system looks considerably more complicated than -fstack-protector and should be noticeably slower too.
If I understood correctly, -fstack-protector simply adds a guard value and checks it hasn't been overwritten. The performance overhead is minimal. On the other hand, mudflap does some rather intensive checking that involves things like lookup tables, which obviously has to take more time than checking
Re:gcc! (Score:5, Insightful)
Why?
Nobody cares about stack smashing protection anymore these days.
OpenBSD [openbsd.org]
Hardened Gentoo [gentoo.org]
GCC 4.0 has libmudflap and -fmudflap for C and C++. While this isn't exactly the same as stack smashing protection, it is still very effective and much more efficient.
Last time I checked GCC 4.0 wasn't stable.
It's not entirely without reason that IBM still hasn't posted ProPolice for inclusion in the FSF GCC mainline. The patch against SUSE's hammer branch has been floating around literally for years, but they know really only very few people truely believe it makes a difference.
That's crap. Propolice does exaclty what it is supposed to do. It doesn't protect against all stack smashing attacks but no one ever claimed that it did.
Re:gcc! (Score:5, Informative)
Icecream [kde.org] is created by SUSE and is based on ideas and code by distcc. Like distcc it takes compile jobs from your (KDE) build and distributes it to remote machines allowing a parallel build on several machines you've got. But unlike distcc Icecream uses a central server that schedules the compile jobs to the fastest free server and is as this dynamic. This advantage pays off mostly for shared computers, if you're the only user on x machines, you have full control over them anyway.
Re:ProPolice (Score:5, Interesting)
Not by technical choice, they want to use plan9's C compiler but have licence quibbles.
Quoting Theo : "in particular we were interested in the c compiler" [google.com]
Re:gcc! (Score:5, Informative)
I also heard reports from people about Gentoo not completing the basic installation when trying to do with with distcc even without the stack protector.
The idea itself is really nice, but at least for me doesn't seem to work nearly as well as it should.
Re:gcc! (Score:4, Informative)
Re:gcc! (Score:5, Insightful)
My view on the whole open-vs-closed debate is whatever gets the job done. There are a lot of open source tools that get the job done quite well, and I use those. But there are also occaisions where proprietary software gets what I need done quicker and easier, so I'll use that.
Re:gcc! (Score:2, Informative)
I was supprised to see that.
Maybe on a risc platform I could see buying a proprietary compiler.
Re:gcc! (Score:5, Interesting)
Have you actually tried other platforms? The best compiler on a given architecture is usually the chip vendor compiler -- IBM's compiler beats GNU on PPC 970, HP's beats GNU on Alpha, etc.
Sure you can find the odd piece of code where Gnu will beat vendor compilers but overall, and particularly for large scientific workloads, vendor compilers win for raw speed.
Re:gcc! (Score:5, Insightful)
"is $x > $y?"
This is only true if you include all costs and benefits, not just the sticker price.
Commercial vendors would love for customers to consider only the sticker price without taking into account the many hidden and recurring costs in most commercial software solutions.
---
Astroturfers are scum.
Re:gcc! (Score:5, Funny)
Seems like there's an "In Soviet Russia" joke in there somewhere.
Re:gcc! (Score:4, Insightful)
Re:gcc! (Score:3, Informative)
Re:gcc! (Score:5, Informative)
--
ken_i_m
Founder, Bozeman Linux User Group
3.5 vs. 4.0 (Score:4, Interesting)
Re:3.5 vs. 4.0 (Score:5, Informative)
More info on the GCC site [gnu.org]
Re:3.5 vs. 4.0 (Score:2)
Re:3.5 vs. 4.0 (Score:4, Informative)
I'm not sure, but I'd guess that 4.0 is the place where major development is happening, where major changes/improvements are made, whereas 3.5 is where minor/incremental stuff is being done.
I'm afraid you're wrong. 3.5 is the current development version of GCC. Amongst other things (which include a new Fortran 95 frontend -- hurrah!), it uses a wholly-new optimization architecture known as 'Tree-SSA'. This change is so radical that it was recently decided that 3.5 should actually be released as new major revision -- i.e., 4.0 -- rather than as 3.6 (recall that many open source projects use odd minor version numbers for development branches, and even ones for stable releases). Therefore, 4.0 is what 3.5 will be once it is released as stable.
You may recall that a similar version renaming was mooted for the latest Linux kernel, but it was decided to leave it as 2.6 rather than 'upgrading' it to 3.0.
The even-odd thing... (Score:5, Informative)
...does not apply to GCC. Never has. And it will not in the future, unless we radically change the way we do development and releases.
3.4 follows 3.3 follows 3.2, and none of them were singled out as "developmental" or "experimentalal" or "extra stable". The experimental-vs-stable changes all take place before any release branch is made. There's more info on the website if you want.
Re:3.5 vs. 4.0 (Score:5, Interesting)
The problem is the GCC codebase is so badly designed it takes major changes to many parts to introduce a very old concept of SSA into it. So you can't take advantage of a generic SSA but have to introduce different patches for the system.
Back in my university days we did SSA in our own compilers, for a 5 week course! GCC needs a complete rewrite or a switch to something like TenDRA [tendra.org], which right now produces good solid code, but not extremely optimized machinecode. On the other hand TenDRA is really well designed so it would catch up really fast if more people worked on it.
Re:3.5 vs. 4.0 (Score:3, Informative)
I would certainly hope there will not be a GCC 3.5 created by someone else. Can't think of any reason to, really.
From GCC 3.3 onward, almost all development of GCC was centered around the tree-ssa project (the new optimization framework for GCC 4.0) and even though bits were in GCC 3.4 (unit-at-a-time for example), there really isn't any major new functionality in GCC 4.0 that is easily backported to GCC 3.4 that would suddenly make it different enough to call it GCC 3.5
And even new major functionality
Re:3.5 vs. 4.0 (Score:5, Informative)
The GCC Steering Committee changed the next version of GCC from 3.5 to 4.0 while I was in the midst of writing the article. I missed changing a reference; the typo is now fixed.
Very informative. (Score:2, Interesting)
I don't get it... (Score:3, Funny)
That doesn't seem right; I know that Gentoo is able to adapt itself to your hardware, but this is a bit much for me to swallow.
Re:I don't get it... (Score:2)
Re:I don't get it... (Score:5, Informative)
It's called a "typo". Fixed.
Re:I don't get it... that you don't get it... (Score:3, Informative)
AMD64 kernel
Intel P4 processor
Sure you can compile for AMD64 for if you like, but if your processor is an ordinary Intel Pentium 4 you probably won't be getting many benefits from doing so.
As some of the more insightful people have pointed out, there is a difference between mcpu=x86-64 which will make optimaztions assuming amd64 architecture (which is just silly, as you'll get no gains from it on a Pentium chip), and march=x86-64 which breaks binary compatabili
Re:I don't get it... that you don't get it... (Score:2)
Re:I don't get it... that you don't get it... (Score:3, Informative)
If you had actually read the article, you would have seen:
Corwin (Homebrew)
Gentoo AMD64 GNU/Linux, kernel 2.6 SMP
Dual Opteron 240, Tyan K8W 2885
120GB Maxtor 7200 RPM ATA-133 HD
2GB PC2700 DRAM
Radeon 9200 Pro, 128MB, HP f1903 DFP
Tycho (Homebrew)
Dual Boot: Windows XP Professional
Gentoo x86 GNU/Linux, kernel 2.6 SMP
2.8GHz Pentium 4 w/HT, Intel D850E
apples and oranges (Score:2)
Hmm?
Re:apples and oranges (Score:3, Funny)
As you know, Intel is very eager to improve performance of processor architectures that are competing with their own.
Re:apples and oranges (Score:4, Informative)
If you must have optimized support for AMD... (Score:3, Interesting)
It's nice, but much less free. 15-day free trial. Prices are not bad, but it's still a little steep, even for an academic license.
This is not a plug... just in case anyone was wondering if there was something besides ICC you could try in to benchmark GCC on something that ICC can't cope with.
Re:apples and oranges (Score:4, Informative)
Re:apples and oranges (Score:4, Interesting)
Re:apples and oranges (Score:2, Insightful)
Unless you are targeting for binary compatibility among different architectures, the question is somewhat meningless. If you need to compile from the source, you may very well use a faster tool for the job; it can be Intel for Pentiums, and GCC for the rest.
Granted, if you want to deliver a binary that runs on other platforms (by means of emulation or whatever) you better stick to GCC. Now, how many times do you need this?
I believe the author of the article himself is stating that in the end you should be
reverted (Score:3, Informative)
Binary size (Score:3, Interesting)
Re:Binary size (Score:4, Informative)
Re:Binary size (Score:4, Insightful)
Who cares about memory when hard drives are so slow? Reading from laptop HDs is especially painful and binary size does come into play.
Re:Binary size (Score:3, Insightful)
In particular small code can make apps start faster, and the whole computer feel more responsive. The day computers never swap and disk I/O isn't a bottleneck will be the day we can ignore code size in compiler benchmarks.
Performance isn't everything. (Score:5, Insightful)
Re:Performance isn't everything. (Score:2, Insightful)
Re:Performance isn't everything. (Score:2, Insightful)
Re:Performance isn't everything. (Score:3, Informative)
And how likely is GCC to continue supporting the features you love? In case you haven't been checking, gcc-3.4 has removed some of its extensions to C grammar (the old joke used to go that gcc can accept a perl script as valid input). I use Gentoo, and after gcc-3.4 was released, I frequently encountered programs that r
Re:Performance isn't everything. (Score:3, Insightful)
Re:Performance isn't everything. (Score:3, Informative)
Re:Performance isn't everything. (Score:3, Informative)
Re:Performance isn't everything. (Score:2)
Re:Performance isn't everything. (Score:5, Insightful)
That is why it is important to compile your code using multiple compilers. Prefer to write code to the C/C++ standards rather than to a particular compiler's idiosyncracies, GCC included. Different compilers also emit different warnings, helping one find bugs sooner.
Re:Performance isn't everything. (Score:3, Interesting)
You can say that again. We had a bug recently in some code that gcc compiled without any warnings or problems but the code didn't work right. Compiled it with another compiler and got a warning in the code, looked at it, and sure enough, that was a legitimate bug. Corrected that line of C, recompiled on that compiler and gcc and both executables worked.
Re:Performance isn't everything. (Score:4, Insightful)
Nonsense. GCC has way too many extremely useful "idiosyncracies" to abandon. If you don't know what they are, then you aren't paying attention.
Better that other compiler makers mimic GCC's behavior. Better still is for the standards groups to adopt GCC as the reference standard for C and C++ compilers.
Re:Performance isn't everything. (Score:2)
I think the key is to write good code first, then take advantage of the optimizations ICC provides second. Intel won't lock anyone in, but they'll put the lock on the door. Whether you close it behind yourself is your own choice.
--Dan
You can run intel binaries on opteron (Score:2, Informative)
Aces article [aceshardware.com]
I am dissapointed in Intel (Score:5, Interesting)
However from what I see is the performance of the compiled code is the same with the exception that the resulting binaries are alot bigger.
Maybe gcc is good on x86 but sucks on other architectures? I know the Sun and SGI geeks have complained for years that gcc does not run well on their platforms compared to expensive alternatives by their vendors.
Has anyone run ICC and VC++.net on Windows? How does it compare to Borland and MS compilers under Windows2k?
Vectorization? (Score:5, Interesting)
I think the author had better mark the tests whose inner loops have been vectorized, since while some algorithms are easily vectorizable, some are not, so the performance of both are interesting. After all, we care most about the features (such as automatic vectorization) of the compiler, while benchmarks only very roughly reflect the existence of such features, the applicability of them, and their effects.
Re:Vectorization? (Score:5, Informative)
GCC 4.0 (which is, of course, "in development") has recently included automatic vectorization -- another of the "good things" that will be coming with the new architecture.
My next article will compare automatic vectorization and profiled optimizations.
C++ compile times? (Score:2, Insightful)
Re:C++ compile times? (Score:2)
Nope. It's not that they don't care about you, it's that they have their priorities in order. Download the binary if it's going to cause you considerable pain to compile.
This guy must be a nerd... (Score:5, Funny)
You can tell this guy is a nerd, but it goes far beyond the pizza and mountain dew... Is that [coyotegulch.com] really an empty tub of frosting sitting my his computer??
Re:This guy must be a nerd... (Score:5, Funny)
Yes, it is frosting. Chocolate frosting. How else can I maintain my svelt figure?
Re:This guy must be a nerd... (Score:4, Insightful)
Wolfram has some interesting points, but I think his ego has gotten in the way of good science. With his "New Kind of Science", Wolfram hasn't really "invented" anything; he's mostly implying meaning where it may or may not exist.
On the other hand, I do believe that higher order derives from basic, simple, underlying processes that combine in great complexity. Turning that supposition into real science is something I hope to see happen in the next century.
commercial thinking (Score:4, Informative)
It fails to point out that compile times are a fairly critical factor in programmer productivity. Yes, we should care that compile times with the Intel compilers look to be over 25% shorter than with gcc on average. (very rough eyeball estimate)
I am amused, also, at how perplexed the author seems that IBM would ship Eclipse 2.x (and CDT 1.x, its associated C/C++ plugins) with the compiler. The CDT plug-ins for Eclipse 3.x were only ready a couple of months ago, so this is plainly a matter of how much time and money the Intel team had to test them with ICC. Or maybe they weren't available yet at all: when WAS the Intel 8.1 compiler released, anyway?
Compile time (Score:3, Interesting)
I can see it compile time being important to people who use the compiler as an
C/C++ vs. Fortran (Score:5, Interesting)
I find it interesting that there are only two C/C++ compilers available for Linux, as compared with seven [polyhedron.com] Fortran 90/95 compilers (soon to be eight with the release of GCC 4.0). This not only dispels the myth that Fortran is a dead language, it also suggests that there is much more of a competitive market in compiling numerical code, than in producing other types of software.
Re:C/C++ vs. Fortran (Score:3, Interesting)
I'm working on a Fortran 95 comparison, which will include several products.
Most people doing serious numerical work are creating proprietary or in-house applications; few people have the clusters required to run the type of code written in Fortran. So there is a commercial market for Fortran; places like National Laboratories and universities have the money to buy software.
Re:C/C++ vs. Fortran (Score:5, Informative)
1. GCC [gnu.org]
2. Intel compiler [intel.com] (Intel only)
3. Comeau [comeaucomputing.com]
4. PathScale [pathscale.com] (Opteron only)
5. Portland Group (PGI) [pgroup.com]
6. Borland [borland.com]
gcc 3.4 still a little unreliable (Score:3, Informative)
In short, I don't have much confidence in the optimizer in 3.4. I'm trying to condense the problem to a testcase right now to submit a bug report.
Re:gcc 3.4 still a little unreliable (Score:3, Informative)
If you're not prepared to assume it's a compiler problem, then why do say your code "gets miscompiled"? That sure reads like an accusation, which you acknowledge as being unfounded in the next sentence.
OK, let's try this again. I'll type more slowly, so you can understand.
The code is fairly complicated. It passes unit tests under 3.3 regardless of options. Under 3.4 without optimization it works fine, but when I use -O2 it behaves differently. Either my code is broken in a subtle way that only manifes
Interesting image. (Score:3, Funny)
Re:Interesting image. (Score:4, Funny)
Coke goes better with rum.
Well, that's my opinion. My wife insists that Diet Pepsi (ugh!) is a better mixer, but then, her sanity is in question given that she married me.
Re:Interesting image. (Score:3, Insightful)
Sounds like jealousy to me... ;)
LLVM and C++ (Score:4, Interesting)
Of course, the real fun will begin when it has completed Java and C# front-ends.
GCC usually whips ICC for me (Score:3, Interesting)
Also, in my experience, the C++ standard library that shipped with the previous versions of ICC just wasn't that good. Well, that may be a little harsh, but it was a source of considerable irritation to me that ICC's implementation of valarray did not even use expression templates (hello temporaries!). Yes, I know valarray isn't all that, but it is standard C++ (hence, in principle, code that uses it is portable). Once again, the GCC implementation was very much superior. This may be part of the reason why ICC now uses GCC headers.
(As an aside, I did roll my own implementation of valarray that uses expression templates. I tested it with both GCC and ICC, and GCC still won.)
I am now curious to test whether things are indeed better with ICC 8.1 (the last version I tested was 8.0). Maybe this time it will actually speed my code up rather than slow it down.
A few editorial notes. (Score:3, Informative)
Quoting the article:
Actually, the name of the license is the GNU General Public License. It is "General" because when the GNU project began there was no single license used throughout the project [free-soft.org]; .
GCC can be commercial [gnu.org] too -- many firms distribute copies of GCC for a fee. I believe the author should have said "proprietary" meaning that what the Intel compiler program does, exactly, is secret. As RMS said when describing a proprietary web video streaming application he didn't want MIT to use to distribute a feed of his talk on copyright and globalization [gnu.org]:
GCC, by contrast, is free software licensed under the GNU General Public License. Getting back to the article:
Here I don't think "open" was the best choice of words, I think "free" would have been more accurate. The GNU Compiler Collection was originally the GNU C Compiler and first written by RMS. I guarantee you that RMS did not and does not now do work for the open source movement. He makes effort to make that point clear [gnu.org] (like when he corrected Mike Uretsky who made the same mistake). The FSF asks you not to lump their work in with the work of the open source movement [gnu.org]. Eben Moglen spoke at Harvard [groklaw.net] some months ago and also made this distinction. Prof. Moglen makes it clear why they are so adamant on this point:
I don't think he's overstating the case.
Finally, there's a common misunderstood myth repeated in the end of the article:
Many people believe this, I've even heard a variant of this myth being repeated by a representative of the Mozilla Foundation. Choice is no substitute for software freedom, in fact they speak to different aims entirely and in computer software choice is not as important as software freedom. If all we have are three web browsers to choose from (say, Microsoft Internet Explorer, Netscape, and Opera) choice is satisfied. B
Re:A few editorial notes. (Score:3, Informative)
You can not have freedom without choice. Competition in a diverse environment is the engine of evolution; any monoculture stagnates. I no more want a world run by RMS than I do a society that is beholding to Mr. Gates. A pox on both their monopolistic houses.
I believe in the competition of ideas, and strongly support and defend the conce
Compatibility issues (Score:3, Interesting)
Also, the ability to compile a C++ DSO without requiring the exact same compiler version as the program that will load it, is a major need for commercial Linux software vendors.
Silly gcc optimizations (Score:4, Interesting)
[argh...lameness filter refuses to allow source code]
I'm providing a link [slashdot.org] to my journal entry so that I can post these examples.
What about documentation to write new front ends? (Score:3, Interesting)
Re:What about documentation to write new front end (Score:3, Insightful)
Re:What about documentation to write new front end (Score:3, Informative)
And I don't need lessons on yacc and bison.
I think you probably do need lessons on yacc and bison, if you think "yylex()" is an obscure name. It's the totally standard name for the lexer callback used in yacc and most of its clones. And the relevant section of the Bison manual is the third hit when you google for it -- so much for "no decent documentation"!
Methinks you could have chosen a better example...
compiling linux with a different compiler? (Score:3, Interesting)
I would be truely intrigued at what overall performance might be like.
1983 called.... (Score:4, Funny)
1983 called and it wants its programming language back.....
Re:GOT IT! (Score:4, Informative)
let's you forget the #include, and the missing return value
Re:Not a lot of selection for Linux compilers, eh? (Score:2)
It's important to remember that open source projects often contain significant internal competition, even if they're monopolies like GCC or Apache.
Re:Not a lot of selection for Linux compilers, eh? (Score:2)
It would be nice to have more of a selection under Linux.
Re:Not a lot of selection for Linux compilers, eh? (Score:5, Insightful)
The problem with the "good old days" was that as my friend Dave Dunfield said once "C compilers are a dime a dozen".
Just because you had a dozen C compilers for your 8086 doesn't mean you were better off. In fact most compilers for the 86 were crap [e.g. smallC, byteC, Zortech, paradise, etc...]. In fact the only half-way decent 86 compilers I recall are Turbo C [v3.01 was ok] and Micro-C [by Dave Dunfield so maybe I'm a bit biased there...].
Note I'm not saying more compilers is bad. The problem is like any field "new" doesn't imply better. You have to tackle problems and answer them.
For instance, GCC is rather large and can be slow/memhog on some files [C++ in particular]. A viable competitor for Linux would be one which optimizes decently while not being such a hog. It could pitch in when you can't build a file [say from VisualBoyAdvance which requires ~1GB of ram to build with GCC 3.4.2]...
For the most part though, contributing to GCC makes more sense than writing your own compiler. First off, GCC is a "standard". So you're likely to get a huge audience that way. Second, GCC is already well established. It's a very good suite of tools and frankly hard to compete with. Third, you'll save a lot of time.
For all intents and purposes you could change your argument to why do "linux" boxes only run the Linux kernel? I mean for all intents and purposes you could write your own kernel that was interoperable and use instead. For the same reason why contributing to GCC is a good idea so is contributing to the kernel [instead of writing your own] is a good idea.
One last caveat before I send this post. I do agree though that writing such said tools [kernels or compilers in this case] are a good idea for educational purposes. It means a lot to know how to write a functional [and ideally half-way decent] compiler even if it only targets one platform and covers only part of a language.
phew...
Tom
Re:Mod up!! (Score:2, Funny)
This is a classic...
Re:Not a lot of selection for Linux compilers, eh? (Score:2, Insightful)
That's most likely because the market for compilers has become more mature. There are usually fewer players left in a mature market than in a new one. It doesn't necessarily have anything to do with open vs. closed source.
Re:Not a lot of selection for Linux compilers, eh? (Score:2)
Somehow, I think it's pretty much _always_ been a one-gcc show on Linux.
Re:Not a lot of selection for Linux compilers, eh? (Score:2)
I don't consider your message to be flamebait. There aren't many C and C++ compilers for Linux. Several companies make Fortran 95 compilers for Linux, but few seem interested in the C community.
Re:Not a lot of selection for Linux compilers, eh? (Score:2)
Since people
Re:Not a lot of selection for Linux compilers, eh? (Score:5, Interesting)
TCC (tiny c compiler).
Compaq Alpha C compiler.
OpenWatcom C/C++ compiler
TenDra C/C++ compiler
egcs compiler (which merged into gcc- they saw that it had some advantages.)
ChEmbeddable
Cint c/c++ interpreter (not exactly a compiler)
CC65 Commodore C compiler
Absoft C/C++ Fortran compiler
lcc
These all run on linux. Some are open, some are not. GCC is used mainly because it is portable to just about anything-- so there goes your argument of GCC restricting choice. GCC exists to promote choice, and it does this.
Take your code written for Visual Studio and compile it on Sun. Can't do that with Visual Studio? No MFC on Sun? Your best bet will probably be good old GCC with WINE. So how are you restricted by gcc?
Now, if you want to make a cross compiler to compete with gcc- one with seperate front ends and back ends, so it can accept multiple languages, and can compile to just about every machine on earth-- then nothing is stopping you. Oh, what is that? Not interested. Neither is anyone else. Programers see no need to duplicate something that has been done well the first time. One good cross compiler is enough- GCC represents a NATURAL MONOPOLY.
Re:Not a lot of selection for Linux compilers, eh? (Score:2)
When I first wrote reviews for the early geek magazines (anybody remember Microcornucopia?), I could cover a dozen or more compilers for DOS. Today, the field is very thin. :(
Re:illogical hostility? (Score:5, Insightful)
The hostility mystifies me. I'm a semi-active participant in the GCC mailing list, and the people who work on GCC are very helpful, open, and communicative. Some even thank me for my QA efforts.
I don't see that my article is negative about GCC; in fact, I'm very clear that Intel's compiler isn't a replacement for GCC, and that GCC is a fine product. Maybe the complainers can't read?
Re:illogical hostility? (Score:5, Informative)
The complainers can't read. I'm a member of the GCC steering committee, and I'm very happy with Scott's work (sorry, dude, I'm not going to call you "ChaoticCoyote"). It's not perfect, but it has helped to improve GCC.
Re:Believe this? (Score:3)
Ah! A typo! I cut-and-pasted the OS test, and forgot to change "AMD64" to "x86" for the Pentium 4. I just made the trivial edit.