Hacker News Reader

Comment by hosay123 | Hacker News Reader

Certain "journalists" are seriously jumping the gun if they assume GCC is just going to shrivel up and die. In addition to mainline, it is used privately in a hundred different branches, several of which are commercially supported (e.g. Codesourcery, Google Native Client) and many the public will never know about.

There is a vast body of consumers who care more about maturity and stability than a few convenient front-end tricks, which the majority of C++11 ultimately amounts to. As for whether GCC is somehow "too far gone" to catch up, well that's just nonsense, the core technology has barely changed in 10 years. Things will improve when commercial needs arise and as eager PHDs hunt for final year projects.

While ancient, there is immense diversity in GCC's configurations, and AFAIK its code generator still maintains an edge over Free alternatives. Of the purported speed improvements elsewhere, anecdotal evidence from my Macbook suggests LLVM is slower at building smaller projects (predicted long ago by smart types that knew LLVM was only fast because it lacked features).

It's worth noting that GCC already supports significantly more C++11 than either MSVC11 or ICC, although this article makes no such comparison. Like the majority of articles from Phoronix, this one is blinded by the new hotness (LLVM) and a generally superficial appreciation of the subject matter.

View on HN

Yawn. Look, i'm actually a GCC maintainer. I was heavily involved in GCC development for quite a while, though I now work more on LLVM. I'm still a listed GCC maintainer. I guarantee you, without a doubt, that GCC will die out on its current path.

The only thing that could stop it is if it's no longer an FSF-run project, or the steering committee actually started replacing older members with people still working on GCC, or something else drastic. This would enable folks to do things that currently take a lot of energy to fight about. It may also have to compromise some core values in order to serve the most users.

Yes, LLVM currently lacks optimizations GCC has. But LLVM will do the same thing GCC did to commercial compilers when we started the tree-ssa project, and cherry pick the high end of research, and implement it (it has already started).

As long as GCC stays on the path it is, it will die. It will be a long time, because it has a lot of users. LLVM is friendlier to developers, researchers, and users. GCC can't win any fight as long as that is true.

FWIW: I also don't think most GCC developers harbor any illusions about the above. I think RMS may, or may not be involved enough to care, but nobody seriously involved in GCC thinks that GCC is in "a-ok great shape no problems"

The other possibility, of course, is that LLVM will end up on the same path GCC does, and thus, they will be on the same terms again. I doubt this, since Chris Lattner saw what happened when he tried to merge GCC and LLVM, and despite his flaws, is much more savvy about politics and community policies than GCC is.

Was "Yawn" snark really necessary to make your point?

Actually, I thought I had removed it before I hit submit. Sorry, it was a bit snarky.

Discovering that the only reply to well-written comment from a subject matter expert is an off-topic critique of one word is both annoying and disappointing.

I'd suggest no more than the snarky "journalists" opening and certainly not as snarky as the rest of hosay123's.

An interesting analysis, thanks! I hadn't realized there was an actual attempt at merging GCC and LLVM. What did happen when it was attempted? Are there mailing list posts or suchlike from the time, that would clarify things?

I can't even remember what year it was, but if you start searching the gcc and gcc-patches mailing lists for emails from Chris Lattner, you can find a proposal was made. Google may be able to find it easier.

A lot of discussion of this proposal happened offline. The end result was basically that Chris withdrew it (though not formally), though GCC would have rejected it anyway.

GCC was mostly unwilling to throw away what they had (nobody was really up for rewriting everything again), and Chris realized it would be a disaster to his community. Imagine trying to unify the stereotypes of the ruby and python communities, or something like that (i use this only as an example of the level of difference in ideologies between the GCC and LLVM communities)

In practice, this was probably the right social outcome given the set of developers/people involved on both sides. From a pure technical perspective, it's much harder to say.

Ah, thanks, found it. http://gcc.gnu.org/ml/gcc/2005-11/msg00888.html

GCC already "shriveled up and died" once -- the egcs project got so far ahead of regular GCC in development that the FSF basically just said, "congratulations, you are the new maintainers and your project is now the official GCC mainline".

GCC is stagnant, but the dynamic pace of development on the Clang front means that either the GCC developers will adapt, or the community will adapt GCC for them.

There's a bit of a difference, though.

For one, there wasn't any viable competition at the time. Your options were GCC, or a commercial compiler. If you actually needed access to the source code of the compiler for any reason, GCC was your only option.

So, when it became clear that the FSF and the community wanted to take GCC in different directions, the obvious choice was to fork GCC. The fork developed far more rapidly than the original, draining developer time (and users, for that matter) from GCC mainline. Basically, at the point where the FSF anointed egcs as the new GCC, the original GCC project was already dead.

Things are a bit different nowadays.

There are already disagreements between what people wanted to do with GCC, and the FSF. Especially around the tool support the article talked about - the FSF are against reorganizing GCC so that parts can be used as a library for political reasons. They were against plugins for the same reason originally. They have been resisting any attempts to clean up or modernize the codebase (they've been doing it, but very slowly, because it takes the steering committee a long time to... erm... steer).

There's an alternative - Clang / LLVM, which is built around that kind of tool support, has less niche stuff to get in the way, cleaner, simpler codebase, no legacy stuff. A good few GCC developers have jumped behind that instead, rather than trying to work against the FSF, and Clang isn't having the kind of problems attracting new developers that GCC is.

At this point, it does look like GCC is in trouble. The problem is that there might not be anything that anyone can do about it. As with all large projects with a long history, GCC has a hell of a lot of inertia, and it would take massive effort to shift the direction of the whole project, and make the changes that need to be made, especially considering that they can't just stop and spend a couple of years refactoring (which would definitely kill GCC).

Actually the reasons against plugins and GCC being used as 'a library' went beyond mere politics, it was also a practical consideration as it affected the relevance/existance of GCC.

Back then the there was an obvious threat of GCC becoming little more than a backend/frontend solution for proprietary interests which could lead to the open source part eventually wither and die.

Steve Jobs when at NeXT illustrates this problem as he tried to combine NeXT's proprietary ObjC frontend with GCC's backend and sell it under the reasoning that the 'end user would do the linking', he couldn't legally do so which is how GCC ended up with ObjC support which it otherwise hadn't, atleast not then.

Nowadays open source is established and it's benefits are well proven so these choices may look overly paranoid when viewed in the open source landscape of today, but back then and for a long time in GCC's development they certainly weren't.

The fact that an open source free compiler toolchain like GCC has established itself as such a 'de facto' solution has obviously had an incredible impact on the acceptance of open source in general, not to mention that Linux, the open source BSD's, and tons of other open source projects (and likely lots of proprietary projects aswell) would never have gotten anywhere near where they are today had it not been for the existance of GCC, a top-notch compiler toolchain free of charge and free to distribute.

This is actually not what happened with EGCS at all. EGCS was a political fight. The FSF in fact, fought EGCS all the way until it was completely clear that GCC would die.

Could you provide a source? I'd like to learn more about this. (The politics of open-source software is interesting because the underlying motivations are probably still around and motivating other people).

Read gumby's email on http://gcc.gnu.org/wiki/History

It's the "nice" version.

The reunification is kind of glossed over here, but what happened was the FSF fought it all the way, realized EGCS would win, and accepted it back.

GCC got concessions as part of this reunification. The concessions were that GCC would have it's own steering committee, and that we could appeal any RMS decision to the board of the FSF.

One of the concerns mentioned is "GCC needing to bring in newcomers by young students and experiments from academia, while most new developments these days are using LLVM", i.e. that there _eventually_ will not be sufficient community to make those adjustments. I think that concern is justified and may not even be limited to gcc. Any open source project without significant commercial backing will have problems staying attractive to developers for decades. Why would anybody volunteer to work on a decades old and, because of it, somewhat crusty, codebase for free?

Yes, gcc has commercial backers, too, but I think at the moment most of them are more willing to pay for the support of additional architectures or architecture variants than for new language features (at the moment; that can change if C++11 gets more commonly used)

It's theoretically possible to copy the code from Clang to GCC, but the FSF wants the copyright, so it doesn't seams to be very probable. Another problem is that the license of GCC is more restrictive, so I think that most of the people would continue to work in the Clang.

It's possible to fork the code, but it's more difficult to fork the community. It's the problem that the BDFL have to solve to survive.

> It's worth noting that GCC already supports significantly more C++11 than either MSVC11 or ICC, although this article makes no such comparison

Really great point. I don't understand why this article focused on C++11 of all things. Until recently, gcc had much more complete C++11 support than Clang. Now, it seems they're about on par (if feature tables are any guide[1]). In fact, a couple years ago I was about to switch to Clang but when I started using C++0x I had to stick with gcc because Clang's support just wasn't there yet.

Also, LLVM's C++ Standard Library (libc++) is still pretty immature on Linux, so even if you use Clang for C++11 you're probably going to end up using gcc's standard C++ library anyways!

So yeah, this article is pretty sensationalist.

[1] http://gcc.gnu.org/projects/cxx0x.html and http://clang.llvm.org/cxx_status.html

Phoronix is almost always sensationalist, and often extremely clueless (Phoronix benchmarks, for instance, are more often than not, entirely useless because they're so badly designed).

Never believe anything you read there without independent verification, and even with verification, be suspicious....

It does sound like a bit of a strange assertion. gcc is amazingly core to so much and (in this case importantly) so much commercial. Not even the linux kernel itself has this many things that need it to be continued.

Could it be ousted? Sure, if a gnu (or otherwise foss) competitor steps up and does it better (good luck..) but in that case, no problem. Could it be that the gnu/linux distributions and applications running the majority of the internet will have to rely on a proprietary compiler or die? That's just wildin' - issues aside that's nothing even any of the major corporations could really suggest.

if a gnu (or otherwise foss) competitor steps up and does it better (good luck..)

There is a pretty compelling argument that LLVM and Clang are doing precisely that. And the "toolability" referred to in the article is a big part of that. Clang complete[1] is an example of using Clang to do things that the GNU toolchain thinks are perfectly doable with a box of regex. (Spoilers: they're so not.)

[1] - http://www.vim.org/scripts/script.php?script_id=3302

It would take an immensely ballsy release engineer to approve switching from GCC to clang even for a modestly sized, mature codebase. I can think of at least two Fortune 500s where this will almost certainly never happen: the potential cost incurred by the change would far outweigh just hiring a team to keep the old compiler alive, at least in the medium term.

Google and Apple already have.

Switching compilers isn't that difficult, especially when they're as reliable as GCC and Clang.

Freebsd has switched over to clang - and that os is used as the basis for many types of embedded devices such as network routers.

FreeBSD has had a long outspoken goal of not relying on GPL in the base system, an ideological choice. The transition to clang/llvm has also been very long and will (if everything goes as planned) be finalized in FreeBSD 10.

https://wiki.freebsd.org/GPLinBase

Apple (as they would not accept GPLv3) was stuck with shipping the very old GCC 4.2.1, also Apple wanted to be able to incorporate the compiler toolchain into their proprietary solutions like XCode, something GPL obviously won't allow. Hence funding LLVM while starting work on Clang made sense for them, but again not a choice made (purely) on technological merits.

> Hence funding LLVM while starting work on Clang made sense for them, but again not a choice made (purely) on technological merits.

I think it's inaccurate to portray the move away from GCC as simply political with happy side effects, though avoiding the GPL3 was certainly a prime motivation. Greg Parker has stated on Apple developer mailing lists that the adoption of Clang/LLVM has allowed them to rapidly improve the Objective-C language, and that there are more Apple employees working on the language and compiler today than 10 years ago.

as far as i understand freebsd is there just because some license fanatics want to maintain a commercial-izable alternative to linux. they switching to clang doesn't mean much, because it is most probably a dogmatic, ideological move.

I at one point suggested it was the license as well, but cpercival at the time corrected me:

http://news.ycombinator.com/item?id=1351634

Please stop with the accusations of dogmatism. Regardless of whether you agree with their goals or not, the reasons behind avoiding GPLv3 licensed components are very pragmatic.

The common myths and fear about GPLv3 are far from pragmatic.

I can understand those that only want permissive licensed software for components. This make sense, as otherwise the copyright license will put some requirements when distributing copies of the new work. If its proprietary components, you got to buy a license. If its copyleft components, you got to use a particular license.

But if we are talking about gplv2 vs gplv3, only a very small subset of people will ever have to care about the differences between those two licenses. It actually only comes down to two questions.

1: Are you planning to sell a product, but want to keep root access to the device after its being sold, while at the same time directly preventing giving the same access to the new owner who bought your device?

2: Are you in a patent license agreement with an other company over patents you pay for and which cover aspect of the new product?

If your answer is No and No, to those two questions, you can regard GPLv2 and GPLv3 as identical licenses. Its that simple.

There's also an issue of code contribution that some people will not experience or know about. I'm working at a large company and I can contribute to any FOSS project... unless it's gpl3 or requires a copyright assignment. In that case I have to go via a review process taking weeks to complete and involving 2 levels of management. Or I can simply fork locally, patch and never contribute back (this happens almost every time).

I doubt this is rare inside of large corporations.

The patent agreement part GPLv3 (which is the difference between GPLv2 and GPLv3 in regard to patents), only cover distribution rights. If you do not distribute the whole work, you can create as many code contributions you want and have as many patent license agreement at the same time. They do not interact.

For code contributions, GPLv2, GPLv3 and Apache license has the exact same deal in regard to patent grants. Actually, the text used in GPLv3 that cover patent grants of contributors, is word for word copied out of the Apache license. GPLv3 only added additional patent requirements for distribution of the complete work. My guess, for the exact reason of not discouraging companies to contribute code.

If the company review GPLv3 contributions, but do not review Apache licensed contributions, they have bitten the FUD apple.

Pretty much the same in any large corporation I worked with.

Not only for contributing, but for using as well, and with every single version change the same process must be followed.

#2 in particular seems impossible to ensure. There's no way to say "No" with any confidence. If you make a product, and someone comes to you with a patent claim asking for money, you put yourself in the position of completely rewriting your project or taking the claim all the way to court on merit. Violating a patent does not require intent, so unless you have intimate knowledge of every possible patent claim that could be made, and you are willing to fight all of them all of the way, you might as well start right off the bat without GPLv3.

There is plenty of ways to say No. If my company is distributing someone else program which is under GPL and then get sued for patent infringement, we would not be willing to pay money per unit so we can continue distribute that software. We would either rewrite the parts covered under the patent or use a different software. But paying for the privilege to distribute someone else project?

If your in a situation where you want to use someones else project, and would be willing to pay per unit to distribute it to your users, what would you pick. A patent deal to get the privilege to distribute a GPLv2 program, or a supported and legal protected proprietary program? I would pick option 3, ie, write my own program or fight the patent depending on which ever is affordable. In this regard, what license the original program was in matter very little if at all.

An ironic statement considering the backstory behind GCC's obfuscation and complexity.

It really depends on the code.

Mozilla switched its Mac builds from gcc 4.2 (or rather the Apple fork of it) to clang, because the cost of doing the switch was lower than the cost of avoiding all the bugs in said fork of gcc 4.2 that didn't exist in the other three compilers the codebase also had to compile with (gcc 4.4 on Linux and MSVC).

FreeBSD is making the change, most of the code for the company I work for is only compiled with clang ... we do government work.

You mean like FreeBSD?

Mozilla switched from gcc to clang on Mac OS X (starting with Firefox 17 last year):

https://groups.google.com/forum/#!topic/mozilla.dev.platform...

I'm confused but didn't Apple just do this for two operating systems.

And then moved their entire OSX and iOS development community as well ?

Apple manufacture consumer entertainment devices that are neither safety critical in nature nor difficult to field test. Think more along the lines of Boeing, Northrop Grumman or Raytheon.

There is a whole industry of people providing operating systems and compilers for high assurance embedded development, led by companies like Green Hill Software. Nobody would ship a safety critical embedded project using either GCC or Clang.

At the highest levels of safety, the DO-178B standard for aviations systems requires compilers to generate code in a way that has a fixed structural relationship between source and output patterns, where each pattern is independently verified, so that every output instruction is directly traceable to a source instruction. All other code generated by the compiler has to be manually verified. This eliminates the use of most of the optimization techniques found in modern compilers. Also, the emphasis on Worst-Case Execution Time (WCET) verification means that performance improvements only matter if your WCET estimates can incorporate them.

Back in 1996-1997 I was a federal contractor working as a software consultant and analyst using several different systems for logistics and provisioning for the US Army to downsize a base to a different state.

We used different operating systems and different databases and programming languages to create a redundant system that solved the same problem or generated the same report. We would have at least three programs running with three different technologies and if the reports were all the same, the system was in good shape, but if one of the reports differed somehow we knew we had to check and fix something.

We did use SunOS/Solaris, HPUX, Linux (Slakware IIRC), DOS/Windows 3.0, Windows 95, Windows NT, etc. In some cases there were C programs using the native C compiler with whatever Unix system that was in use, and in the case of Windows or DOS we used whatever language or software was available. I worked in Clipper, DBase, Oracle PL/SQL, SQL Server, MS-Access, and sometimes even flat text files downloaded from mainframes or FTP sites on the Military network that needed converting to different databases. As a federal contractor I was limited in what I could do, for example my PC did not have a CD drive and they would not allow ODBC drivers to be installed. I did not have administrative access but instead access to a maintenance account that others shared to work with databases that was limited in many ways.

My point is you work with whatever they give you to work with, you may be limited in what you do, but you use what you have available. So yes you might be limited to GCC on a Linux system and no root access to install CLANG or LLVM.

> PC did not have a CD drive

Was this before or after Bradley Manning? (I think he used a CD-RW drive on a "secure" computer to extract the data he sent to Wikileaks.)

> account that others shared

Shared account? Really? Sounds like top-notch security in action. [/sarcasm]

> no root access to install CLANG or LLVM

You don't need root access, you can just do:

./configure --prefix=$HOME/clang

or whatever the equivalent is if clang uses a different build system.

If /home is mounted noexec, that's a real problem, but if you're doing software development, noexec would mean you couldn't run the programs you're writing either.

Of course, just because there's no technical reason you can't do something, doesn't mean there isn't a nontechnical / political reason you shouldn't. If you'd made a project change as large as using a different compiler without approval from (or at least notification to) higher up, you might have gotten in trouble.

It was in 1996-1997 so it was before. They would install the OS and then remove the CD-ROM drive for security reasons. One of which was to make sure no unauthorized software was installed, and yes they had CD Burners back then and saw that as a security risk for copying information.

You will find that not all federal systems are secure and run by experts. Some federal employees are not qualified for their jobs, and that is why federal contractors are hired to make up for it. For example some of our servers and systems were not behind a firewall and had public Internet IP addresses. I agree a shared account is a security risk, and when someone changed the password to the maintenance account we were locked out and had to file a form to learn the new password. In fact to do anything like install software or configure a system we had to file a form first.

Yes the federal government and chain of command requires that I file a request before I use a new software product. Even if it can be downloaded and run in the home directory, if I don't get permission for it, I am in deep trouble. So much as refreshing an IP address, if I do it myself I am in trouble, I have to call their help desk and have them refresh and renew it for me.

You don't need root to install Clang/LLVM.

Actually VxWorks uses gcc (and make for the build system). At level A I think you are required that your tests have 100% coverage, at machine instruction level, but I don't remember there must be that kind of fixed relationship between source code and output from the compiler. I have developed only for level B and have never been involved in toolchain verification, so maybe there is something I am missing.

> Nobody would ship a safety critical embedded project using either GCC or Clang.

They would and they do.

I'm not sure what the second paragraph is trying to say. GCC (and Clang) optimizations can be turned off selectively or entirely altogether.

DO-178B doesn't prohibit optimizations in general.

I was writing some networking code for an avionics project in C, and stumbled upon a bug in GCC that was causing structures to be packed incorrectly in memory. The bug had long been fixed in newer versions of GCC, but it's so time-consuming and money-consuming to approve new compilers for avionics use that we just had to work around the bug.

If upgrading from one version of GCC to another is a big deal, I can only imagine how excited avionics stakeholders wouldn't be to switch compilers altogether.

It may happen eventually, but then again... it may not. Just so long as they are happy to use some GCC build from 2002 or whatever, and just so long as there's no pressing need to use something else, why should they take on the effort and expense of switching?

I'd be surprised and disappointed if those companies were using GCC to compile avionics code written in C++.

Really, why? What should they have been using - at least just a few years ago before LLVM became mainstream?

Probably icc (Intel's C++ compiler), MSVC++, or one of IBM's (i.e., xlcc).

ICC is a proprietary compiler which not only focuses it's optimizations on their own cpu range but also have a history of deliberately generating subpar codepaths for non-Intel cpu's.

MVSC is Windows only proprietary compiler and certainly hasn't had stellar C++ standard support although they are trying to rectify that with their recent 'Go native' push.

I have had no experience with IBM's XLCC compilers though, maybe someone else has?

Are they really that much better? I remember hitting a bunch of incorrectly generated code for MSVC++ at least back in the 6.0 days. Like, the disassembly revealed dangerously incorrect code.

I don't know much about MSVC++, but Intel's compilers are widely considered the most advanced C++ compilers, as long as you stick with Intel hardware. There was some controversy over it generating bad assembly when targeting AMD cores, but this is a non-issue for companies like Boeing and Raytheon, who will be using custom hardware anyway.

The controversy was that it generated a CPUID check for "GenuineIntel" at runtime, and fell back to extremely poorly generated code (like, 386-level, almost 286-level style) for all other CPUs, as far as I remember.

Borderline intentional sabotage against AMD, because they can obviously do better and I don't believe they are unaware of the capabilities of AMD CPUs.

(edit: And they should probably be checking for features instead of vendor IDs anyways. It's like checking for Firefox in the user-agent and sending animated GIFs instead of WebGL if you're on Chrome)

Here's some more info: http://en.gentoo-wiki.com/wiki/Intel_C%2B%2B_Compiler#Uncrip...

Intel is widely known to produce the most _optimized_ code for their own cpu range. That doesn't mean that they are the 'most advanced c++ compilers'.

It was generating bad code for anything that wasn't Intel.

cwzwarich's comment above covers it pretty well.

What else do you propose they should be using?

Does your back hurt from moving those goalposts?

Are you objecting to the removal of "overpriced" (irrelevant opinion) or the addition of specific examples?

You made a claim ("It would take an immensely ballsy release engineer to approve switching from GCC to clang even for a modestly sized, mature codebase"); people pointed out counter-examples (Apple and Google); you move the goalposts. Would it have killed you to admit that you were wrong in the post as written?

There is little motivation in commenting unless in the process I can enhance or validate my understanding. Often this naturally means arguing details until out of breath, or my diatribe is so sufficiently beaten back that I'm too exasperated to continue – at which point the topic will sink in, until reiterated at some later date in some later argument – with a level of belief that cannot be attained unless all alternatives have first been eliminated. I'd much rather die fierce yet wrong than live a life shrouded in vagueness.

> I'd much rather die fierce yet wrong than live a life shrouded in vagueness.

You'd rather be loudly wrong than humbly corrected. A strange sentiment to hold.

So, no.

Well, your post definitely was "fierce, yet wrong." So mission accomplished, I guess!

PhDs don't do 'final year projects'. They don't really do 'projects' at all. They produce a thesis based on original research over a period of three or more years. If a PhD student is starting some kind of project in their final year, they're seriously fucked.

Really?!

Most Phds I know in CS, have done work not directly related to their main research point. Usually in the 6 months before the deadline some way was found to relate the work with the thesis and it got written in those remaining months.

clang++ compiles my code base for work about 4x faster than g++ 4.7, using c++11 features. The end result may be slightly faster in certain situations with gcc, but for almost all of the code I wrote I am spending time in I/O where a little optimisation for a loop won't make a tiny bit of a difference.

(I am pretty certain hosay123 is talking about "time to compile" not "time to run result", so whether your code is spending time in I/O or something else is unrelated; or do you mean that you expect your particular codebase to be resulting in more calls to #include and more time linking?)

I covered both bases. I was suggesting that the time to compile with clang is 4x LESS than gcc 4.7 for our code base. Which IMHO is a lot more important than slight optimisations of loops that don't make a difference in the end.

The end result produced by gcc in some cases is more performant (looking at profiling output), however we continue to use clang because most of our code spends a LOT more time in I/O than it does in certain tight loops that GCC would optimise, and clang produces better diagnostic output, and compiles faster thus we get feedback faster and spend less time waiting for our codebase to compile.

Ok, that wasn't clear to me, as you then went into the detail regarding the runtime performance, which seemed unrelated (like, my attempt to make it relevant made the "4x" become highly confusing, as you seemed to be arguing a tradeoff that hosay123 hadn't gone into). Fair enough.

But you're almost certainly not comparing the same set of optimizations. If you bring the optimization level of gcc down to the point that it generates code as slow as clang, are the compile times comparable?

What makes you believe that I am compiling with optimisations in one, and not with the other.

We don't pass in any optimisations at all, especially during development. We have found a couple issues in the past whereby -O3 or even -O2 would cause GCC AND/OR clang to miscompile code. So we simply dropped all optimisations.

Danger Will Robinson!!! Back when I was at Google, we were advised to tripple-check compiler warnings, manually look for undefined behavior, run valgrind, etc. if we thought we found a bug in the compiler or TCMalloc. A high percentage of claimed bugs in the compiler or TCMalloc turned out to be relying on undefined behavior.

If switching on standard optimizations is causing "miscompiled" code, especially in both GCC and Clang, it's very likely that your code has silent bugs that are revealed by optimizations. Compilers are perfectly allowed to perform very unexpected optimizations where they detect undefined behavior.

One of the gdb gurus at Google was telling me about a bug brought to him by a fellow engineer, where both branches of an if-else had logging statements in them, and the common code after the branches had a logging statement. Only the logging statement after the if-else was logging anything. It turned out that the branch condition was the result of undefined behavior and under very specific circumstances, gcc had optimized away both sides of the if-else. The optimizer had essentially decided that the bool was never true and was never false. This wasn't a compiler bug. For implementation-defined behavior, C compiler are required to do consistent and sane things. For undefined behavior, C compilers aren't required to do consistent or sane things. Essentially, undefined behavior are the corner cases that compiler writers are explicitly allowed to ignore when performing optimizations. A classic example is int i; for(i = 1; i > 0; ++i) could legally be left alone on one line and be optimized away to while(true) a few lines later, since overflow of signed integers is undefined behavior, the compiler is allowed to perform optimizations as if overflow can't happen.

We compile with -Werror, so triple checking compiler warnings isn't required, it won't even compile if there are any warnings.

At one point we were using an older version of GCC, and an older version of clang and both would miscompile different pieces of the code with optimisations turned on. A lot of things have been fixed since then. There were a few cases where the code that was written was undefined in the standard and the compiler could do as they pleased, but there were quite a few cases where that wasn't the case. The places where it was undefined we fixed, the others we never did figure out what was going on. Newer versions of GCC/clang did the right thing, so we finally upgraded, solving a whole lot of the problems.

At this point in time it just doesn't make sense for us to compile with optimisations turned on, so why risk it?

http://architects.dzone.com/articles/gcc-47-vs-clang-31-eddi...

> Certain "journalists" are seriously jumping the gun if they assume GCC is just going to shrivel up and die. In addition to mainline, it is used privately in a hundred different branches, several of which are commercially supported (e.g. Codesourcery, Google Native Client) and many the public will never know about.

Clang is designed to be highly compatible with GCC-dependent projects, from extensions to command-line arguments. What's to stop them from just switching to Clang if GCC's complexity and lack of documentation prevent it from remaining competitive?

Can't say much about the speed except in my case LLVM was marginally faster. Of course, that could be due to the size of the project as you say.

As always, this can be a case of what's best vs what's best for my case.

If you're pursuing a Ph.D. project why would you commit to doing work for the creaky gcc infrastructure when it's clear that LLVM offers far more exciting opportunities?

gcc is dead. It served us very well, but it is time to move on.

As I understand it, a lot of researchers work on Clang/LLVM just because it allows them to focus on the aspect of the system they're interested in. For example, if you want to make a static analysis tool, you can do that with LLVM, but not with GCC. Also, and let's not mince words here, the LLVM codebase is a lot cleaner.

It seems like the open source community is working as it should here: someone designed a better mousetrap, and the world beat a path to his door. This is the way things should be, and the net result is going to be better open source software for everyone. Nobody wants to keep COBOL alive or CVS, so let's not be overly sentimental about gcc.

nobody will miss gcc when it dies. too bad pcc went unmaintained

I thought that OpenBSD developers started to maintain PCC to use it as their's primary compiler. Did something change?

Maintainers left and somehow the decision was to start integrating LLVM with base instead. I think openbsd devs prefer pcc but there is just too much work to do on it and no motivation right now, so LLVM it is

Reply on news.ycombinator.com