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.
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.
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.
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.
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.
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).
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.
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.
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!
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....
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.
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.
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.)
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.
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.
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.
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.
#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.
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).
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.
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.
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.
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?
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)
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.
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?
> 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?
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.
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
One intervening factor, imo, is that adding support for C++11 is a complex and unpleasant enough undertaking that few volunteers are able to do it, and fewer of those are interested in doing so. I would guess most language/compiler hackers would rather hack on something other than the mess that is C++ compilation, if they have a choice (and if they're volunteers, they do have a choice). So it ultimately boils down to what companies want to do, since many enterprises are heavily invested in C++. If someone pays their employees to contribute support for GCC, it'll get done, and otherwise, it's less likely. Not that much different from the Clang situation, where C++11 is only really getting implemented because Apple cares enough about getting C++11 support into XCode to pay for it to happen.
don't underestimate the capabilities of `volunteers', or floss developers; nearly 30 years of apple software was thrown away again and again, and apple jumped to something new without much backward compatibility. So, they enabling sophisticated development by paying is a temporary illusion.
Are you referring to the move to OS X? Apple ran the previous operating system within the new operating system just to run those old apps, and Carbon was provided as a transitional API for many years. I'm not sure what this has to do with anything, really.
A backwards compatibility argument (whatever it may be) doesn't make sense here, as Clang has been designed to be backwards compatible with GCC-based projects.
Last few times I've seen Phoronix articles my impression is honestly "this is a troll website, right?"
But I was pretty surprised by the attitude that surfaced very early in the linked thread on the GCC list, too. Outwardly hostile, as if to say, "well damn, you losers sure better catch up with LLVM right this instant, otherwise you're making lame excuses". I don't have any involvement in either project (other than the fact that I've used and appreciated both compilers), but this strikes me to fundamentally misunderstand open source. Does LLVM have to fail for GCC to succeed?
The argument isn't about one or the other failing. For the same reason Cobol and Fortran are still used and iterated upon to this day, GCC will also never "die". It is deeply ingrained into many toolchains used by many companies. The article if vapor because the moment a company wants some C++11 feature in GCC, they have a value proposition - refactor their code base to work on Clang (which may not have feature parity with all their optimization / compiler flags from GCC) or contribute the missing parts into GCC.
And a lot of companies will still go with the latter. GCC is fine, and won't "die". The systemic problem in LLVM/Clang vs GCC is that the former is modular and has an intermediary language that makes new compiled languages much easier to implement a compiler for. The resut is that if you were to write a new compiler, LLVM is so far and away the best choice it isn't even a content. So it has momentum GCC doesn't, and that momentum means it will see much more active development.
The reason that gcc loses the original context is that rms wanted it that way. The "middle" of gcc is muddy expressly to make it difficult to "plug-in" a proprietary optimizer.
The forced transition to GPL v3 isn't helping. OS X and Free SD are both largely transitioned to LLVM. Linux is a holdout, but how long will it be able to prop up gcc on its own?
'prop up'? I don't follow your reasoning, GCC does not exist for Linux.
As for Linux relying on GCC, Linux relies on lots of GCC compiler extensions, many extensions which exists as a direct result of requests from kernel developers.
You need to patch both Linux and Clang/LLVM to be able to even compile Linux with Clang/LLVM, and the result is unstable, so it's not as if Linux is a 'holdout' by any measure.
I have to agree with Diego Novillo's comment about Clang's parser. Projects like the Clang complete vim plugin come to mind. Ctags/Cscope doesn't really work to well with overloaded functions and having something that "understands" the language rather than just matching patterns helps.
KDevelop has a very sophisticated C++ parser (duchain I think they call it) which even provides semantic information (e.g. you can syntax highlight pointers differently from objects, non-virtual method calls different from virtual, etc.)
But one of the points of Clang's toolability is that you don't have to write your own parser. You can use the compiler's and see what the compiler will see, avoiding inconsistencies as well as unnecessary work.
DUChain actually might even predate Clang from what I've been able to dig up today, but there's a few other points working against Clang supplanting it:
1. DUChain was designed to support multiple languages (since KDevelop does). E.g. there is work going on now to offer first-class JavaScript support in KDevelop, which libclang wouldn't help with.
2. No one has done the work to verify API/ABI compatibility guarantees, porting libclang into DUChain, etc.
> Richard Guenther responded by saying, "Note that we can't
> drive GCC into the garage and refactor it for two years."
Wasn't this essentially what the egcs project did? It's possible that GCC might need another round of this; could doing that provide a potential avenue out of the current troubles?
Why oh why is the drivel from Phoronix repeatedly at the top of HN. In the few cases where I have know people involved in what Larabel writes about they have always said that he blows things out of proportions and that little of what is written is actually true.
Articles which insults the FSF/GPLv3 seem to always get very highly voted on ycombinator. I read phoronix and I hadn't noticed a FSF-bias.
On the other hand, the stories also all seem true. There really is a serious problem with being attached to the FSF being a liability, and RMS really has held GCC back, and is (in my opinion) the main reason clang/llvm has been able to move ahead in some areas (in particular tool support), where for years RMS explicitly rejected any patch which would make gcc "tool-friendly".
I recall Michael Larabel (owner of the site and pretty much sole show-runner) indeed having expressed a personal dislike for FSF, which is further exemplified with a long line of 'articles' were he attacks FSF for just about every shortcoming in the FOSS world he can think of.
So yes, I'd say you are quite correct in your assessment.
I don't know your viewpoints, so this isn't mean to refer to you specifically, but it might also be that one is attached to the GPL3 and doesn't like seeing it criticized. At the least, it has been my experience that many GPL advocates do not appreciate critical discussion of the effects of the license and the viability of less restrictive alternatives.
Two of the top technology companies (if not THE top two), Apple and Google, are backing Clang/LLVM development for their technologies after having been dependent on GCC for a number of years. There must be a reason for that worth discussing.
I learned C programming in 1987 using Turbo C. I recovered several small programs I wrote for the C class and converted them to work on GCC under Ubuntu.
Most of the code didn't need changes, except where it handled strings (or the char *string1 type string) because somehow gets() caused a segment fault and when I switched to scanf() it worked without crashing. When I used the math.h library and the sqrt() function I had to use the -lm switch on the compiler to get it to work.
I rewrote them in C++ using the G++ compiler and found that the std::string works better than the old C string, and that the cin and cout commands work better than gets and scanf.
I really don't see much of a problem unless you are converting Pre-ANSI C code to the current standard or something. I think that the scope changed, but back in 1987 we were taught to keep variable names used in functions inside of functions, etc to keep the scope the same and don't try to access something out of scope. I guess that is why my programs converted so easily? They also didn't need a lot of resources or libraries and were simple programs written for the command line for DOS using Turbo C.
Should I use CLANG or LLVM instead? How about Visual C++ or Borland C++? Am I doing wrong trying to learn GCC and G++ or should I try learning under a different C++ compiler?
Something interesting to note is that the complexity and internal coupling in GCC was an intentional design decision by GNU to make it harder for non-free software projects to make use of gcc.
Here's a pretty good talk about the philosophical motivations behind Clang and the current work being done on it:
Although the Clang developers claim GCC was poorly adapted to non-compiler use on purpose, the GCC developers seem to have been very eager to accept patches that make these use cases work better. If they were truly opposed to people using GCC as a module in a larger system, why would they go out of their way to encourage modularization?
And please don't link to that RMS email as "evidence"; RMS has about as much control over GNU projects' technical details as Charles Manson does over the music industry.
I remember being somewhat excited about the "GCC Introspector" project, which was a modification of GCC that allowed it to dump XML from various stages of GCC. I also remember that it was very negatively received on various occasions. You can use this situation to find non-RMS examples.
By your own words, you've been working for three years on trying to get information out of GCC for use in other tools. Even if you have no intent of trying to attach proprietary back ends to GCC, you are working very hard to enable others to do so.
...
> I think the GCC list has to ask itself how long are we going to wait before addressing the issues at hand, and not just ignoring the problem to death.
As long as possible, because as long as there isn't a really clean way to attach proprietary front ends and back ends, people who are on the fence about going proprietary or submitting their code back will choose the latter.
(To note: James Michael Dupont, the person doing the work on Introspector, himself was perfectly fine with the licensing even being quite explicit that things attached to his XML data feeds would have to be themselves GPL. This was clarified, and people seemed to understand; however, his work was still being explicitly rejected as it could lead to proprietary backends.)
You still think that I think you're a bad guy. I don't.
Long-term, GCC is going to have to open up the interfaces.
Our current policy is that we don't accept patches that do
this, but we can't prevent others from doing it.
(Honestly, I'm not even certain this is the wrong attitude for the FSF to take, although it certainly is a futile one: you can always build in your own mechanisms to do this, or hell, use one of the new alternatives. It really seems somewhat important that the FSF has been around as long as they have been taking a stance that they refuse to water down; yes, it would be better if we all could work together without this kind of inanity, but the world isn't perfect.)
That implies that the previous lack of modularization was a practical decision, not a political or philosophical one. Implementation of the GCC plugins system started in 2008. Can you imagine the GCC team completely changing their philosophical stance almost overnight (Clang's first release was in mid 2007), just to get more users? It would be as if they'd relicensed to proprietary software to better compete with VC++.
Previously GCC's primary competitor was ICC, and they were compared based on the quality of their output. Now GCC's primary competitor is Clang, and they compete on how user-friendly their interface is. Modularization is a user interface improvement, just like better error messages or more comprehensive warnings.
Until around 2001, GCC supported U/WIN as a host and target platform. The FSF/RMS demanded they remove any code allowing that platform to work, so they did. The GCC project allowing technical decisions to be made for them for political reasons is not new.
That's because the UWIN support had been implemented in a way that caused distributors of GCC to be infringing copyright. This is no different than if the FSF discovered someone had copied proprietary code into GCC. In both cases, the solution is to remove the infringing code immediately.
You might argue that compliance with copyright law is a "political reason", but I think you'd find that to be a very difficult position to defend.
http://gcc.gnu.org/wiki/GCC_Plugins is a good starting point. I have no reason to believe that page deviates significantly from what GNU's. stance was at some point in time.
Another example (this time a private e-mail thread that was made public) is this one, which later became a massive discussion on the FreeBSD advocacy mailing list. Here, as a University project, someone wrote a backend for gcc that generated Java bytecodes (not like gcj, which bypasses most of gcc itself, but a true backend that could generate bytecodes from arbitrary front-ends, such as C).
In this case, Stallman not only indicated that the code should not be accepted, but even requested that the code that had already been published be retracted. He felt that Java bytecodes were sufficiently high-level that they could be used as an intermediate language, allowing closed-source backends to be indirectly connected to gcc's frontends.
FWIW, here again, it isn't clear whether going to RMS was even the right path; it could be that addressing the gcc mailing list in the first place would have caused a different discussion. In fact, even once posted to the gcc mailing list, the response was actually largely positive, although now somewhat colored into a discussion of the e-mail thread, and not the patch; I am not certain (but would love to know) why this patch then continued to not happen.
I am really amazed and disturbed by this email. It seems so absurd that RMS is trying to hold back progress, and keep people from using and expanding gcc as they see fit. In the name of his twisted version of "freedom", he even tries to get Trent to censor the code from his site.
I've always thought RMS was a little off, but I just chalked that up to the typical eccentricities of genius. This isn't just eccentric though: suppressing code in the name of freedom is just plain evil. I'm not sure how anyone can take RMS, and by extension the FSF that he controls, seriously anymore.
> I'm not sure how anyone can take RMS, and by extension the FSF that he controls, seriously anymore.
Well, if it makes you feel any better (or, alternatively, worse, I guess, in which case I apologize :(), I do (to be explicit: take RMS seriously). I didn't in 2002, which is part of why I can pull these examples do quickly: I considered Stallman an extremist and I found his definition of "freedom" confusing. I often had to cite these various email exchanges.
However, over the course of the last ten years of being a developer of open-source tools, I've entirely reversed my opinion. I have found myself more and more frustrated with the attitudes people take towards open source contributors, and I have seen the licenses on my open work become more and more defensive against these abuses (sometimes even using AGPL).
In fact, this whole Apple/Clang debacle was one of the things that pushed me over: this only became "a thing" when gcc moved to GPL3, and seems mostly about Apple wanting to maintain and expand a fully-closed ecosystem, not about technological advantages. In my opinion, the "great GPL purge" of Mac OS X is going to lead to some dire consequences on computing.
Android was designed to decouple GPL code from userspace because OEMs were scared of the "GPL contagion".
The recent Android NDK r8c (November 2012) includes clang 3.1 as an experimental alternative to gcc 4.6. This suggests that it may become the default in future versions of the Android NDK. If Google, like Apple, drops gcc for clang, which major commercial entities will be helping to fund gcc development?
I'm amazed I've never seen this get more publicity.
The fact that RMS would tell someone to take a GPLed extension to GPLed code off their website, and never mention they exist, seems fundamentally against the principles of free software. How was this not a controversy of the highest order at the time? I'm amazed I missed it.
I would say it is against the general principals of "open source" as you might find embodied in the modified BSD license (or simply in the notion of the public domain); but "free software" is more about the enforcement of a social contract, one where everyone has agreed that the "payment" we receive by providing software to the community as open source is that others will also contribute to the shared pot (as opposed to "freeloading"). In a perfect world, it wouldn't be needed, but we don't live in a perfect world.
That said, I agree that this example sucked: the argument wasn't even that strong, party because I get the impression that Stallman doesn't really "get" Java (based not just on this example, but from other situations where Java comes up; it just seems like he never looked at it very closely to see what it really wasn't actually capable of: he seems to give it much more credit than it is due). The comments on the mailing list seemed to defeat his argument, which is why I continue to be confused that the discussion didn't continue.
As for why more people don't know about it, I don't know: it was a somewhat big deal on a bunch of mailing lists (again: it hit freebsd-advocacy and turned into a major event, somewhat bolstered by the GCC Introspector guy I mentioned elsewhere in this thread getting involved an sharing his stories as well). I can only imagine that not enough people care about mailing list history. :(
Parts of it are implemented. But parts of it aren't, and there have been similar cases where something was standardized but never got implemented (e.g. CSS2.1). I'm coming more and more to the position that standardization should happen after implementation rather than before.
Will be implemented and the important bits are already implemented everywhere except GCC, claims of GCC compliance aside. Like, take the standard library for a second--only on GCC must I care about std::unordered_map versus std::tr1::unordered_map. That's a minor pain, but I don't care--I don't feel like dealing with it for GCC platforms (especially given that even after libstdc++ gets right there will be old versions floating around), so I'm only targeting Windows and OS X where clang and libc++ is available.
Do any languages matter? Is it irrelevant that language X does not have a compiler when language Y does?
The answer is that languages are hugely important. C++11 is an entirely huge language and having a standards and feature compliant compiler is critical to being productive in the language.
C++11 itself not theoretical, but the added "improvements" to the language are mostly theoretical. Since adding the template concepts a few years ago, the steering committee has dropped all sense for pragmatic design decisions and replaced it with fashionable-at-the-moment CS-concepts that will not improve your life as a developer in the real world. There is a good reason why most companies limit/prohibit the usage of certain newer C++ features. Using them only adds complexity while not leading to better software (>speed,<size, >maintainability).
As far as I know, GCC and Clang have the most complete C++11 implementations, and I use many C++11 features daily in GCC 4.7.2. (Planning to give Clang another whirl, but haven't gotten around to it yet.)
But neither fully supports it yet, just as GCC doesn't. Even when they claim to support every feature in the standard, that's just the beginning -- next comes fixing all the bugs and corner cases that naturally arise from a spec as complex as C++11.
And? Essentially the same thing happened with C++98, and in the long run it didn't hurt adoption too much. To me, it seems like the compiler are doing a better job this time around.
The point is that it's silly to criticize GCC for having incomplete C++11 support one year after the standard has finalized, and even sillier to point to other compilers' less-complete support as evidence that GCC is falling behind.
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.