(Different poster here.) I like to call it "Moronix" because their analysis is so shallow, but OTOH they cover topics that no other site cares about, so it's probably a net win as long as you read with a critical eye.
Yes I mostly read it to keep up with some of the Mesa developments, I'd agree that a lot of times they jump the gun and report something as more than it is, or even don't give enough information about some reporting (mostly the benchmarking, but they have gotten a bit better about that lately).
I have always wondered why there has never been a competitor site to Phoronix. My guess is that very few people with the interest and ability to understand things like mesa and llvm are motivated to make a website about it.
GCC has resisted modularity for a while because of concerns about enabling proprietary plugins; an unfortunate case of letting ideology come before technical excellence. This left a big unmet need and put LLVM in a stronger position to displace GCC purely on technical merit, by offering this capability that GCC didn't want to offer.
Reading that article from lwn.net is amazing. The irony of the gcc community users screwing over their customers in order to preserve their ideology, and its parallel in the 'commercial' software business is really amazing. Seriously. "We won't make plug-ins because that would open the door to making money on GCC" vs "We require a key disk to prevent folks from copying our software and using it for free."
This is backwards. GCC and the GNU project as a whole exist because proprietary software was "screwing over its customers" in ways rms and the other early FSF people couldn't accept. The "ideology" of free software is (and always has been) the primary motivation, not the "customer" or "technical excellence".
You can flame over that if you like (but please don't: just google the older flame wars from the 90's, this is depressingly well-travelled ground), but don't get confused over the motivations of the actors. The FSF has been nothing if not crystal clear about their priorities.
Not backwards, I think you got it. I lived through the flame wars in the 90s and really resonate with the message "Give us the damn source so we can change it to do what we want!"
The irony is that if folks are trying to check in changes into the GCC tree that allow for plug-in modules because that is what they want, and the community is denying those commits because they fear having a plug-in architecture would enable other people to do bad things. Well that is ironic that such changes would be denied based on a potential transgression for some of the users.
When I read the argument it sounded like what folks had been arguing on the other side back in the 90's, hence the irony.
'Screwing over their customers'? Who are these 'customers'? If you are talking about end users then I fail to see how they are to be served by enhancements being kept in proprietary plugins (which are the historical reasons behind the objection against plugins, which in turn can be illustrated by the attempts of Steve Jobs who while at NeXT tried to circumvent the GPL to have it as a backend for his proprietary ObjC frontend).
The whole point of GCC is to have a complete compiler toolchain where all the enhancements are being made available to _all_ end users. Catering for companies who wants a free strong frontend/backend on which to develop their proprietary extensions is obviously NOT what FSF is interested in and I personally agree with their 'ideology' in this case as the last thing I want to see is a situation where developers keep their enhancements proprietary (likely due to the wishes of their companies who see no gain in releasing those enhancements and instead wants to keep those enhancements as a competitive edge).
Also I like how GCC enforces patent protection grants to be given by code contributors, something which LLVM does not and I fear is something which could open a big can of worms later down the road.
Off course, scoffing at the 'ideology' which lead to the creation of the toolchain that is fueling pretty much the entire open source ecosystem not to mention lots of proprietary projects aswell makes you look pretty stupid in my book. Also GPL is obviously a licence through which numerous companies find it agreeable to cooperatively develop code, hence the success of Linux and GCC.
Ok, so the point is subtle and perhaps not easily communicated. This example is good though.
"The whole point of GCC is to have a complete compiler toolchain where all the enhancements are being made available to _all_ end users." ... "the last thing I want to see is a situation where developers keep their enhancements proprietary."
I believe you have correctly expressed a consensus opinion of why it would be 'bad' to allow proprietary plugins. And your claim posits a reason:
"(likely due to the wishes of their companies who see no gain in releasing those enhancements and instead wants to keep those enhancements as a competitive edge)."
Which is also a common reason given.
However what if there was a different reason? What if there is some capability that could be created with a plug-in that is pretty specialized, further that plug-in would require specialized domain knowledge and would only be of use to a small number of GCC users.
Traditionally the way the market has created such things is that a person invests their time to create the capability, and they charge a fraction of what it cost them to others to use the capability. The compute the fraction to offset the cost of developing it, and the community benefits by getting access to this capability for a fraction of what it would cost to develop in house, and the developer benefits by having the cost of their efforts covered by the community.
In a GPL world where the work would be considered derivative, you remove the opportunity for people to charge for their work, and thus you remove the economic motivation for getting something built. This damages the community as a whole with a somewhat 'invisible' "didn't go there" sort of damage (you only miss something if you had it and then you don't, not if you never had it). It is an unfortunate byproduct of GPL like licenses that they poison[1] the market for those specialized tools.
I completely understand the motivation behind the FSF and GCC communities for wanting to keep GCC available for all.
But you have to also note that people who sell software make very much the same arguments in defense of copy protection. They (the software producers) argue that they want everyone to have the same experience and they can't control that experience if people are out there making bootleg copies and changes they don't know about. So they deny something their customers want "software unburdened by loathsome copy protection" to preserve their stated goal of giving everyone the same experience with their software.
So if the FSF and GCC communities are denying something their customers want "modularized GCC tools for easy customization through plug-ins" in order to preserve their stated goal of giving everyone the same experience with their software, well it strikes me as ironic.
[1] Sorry for inflammatory way that sounds, my thesaurus is coming up blank on terms that mean 'something which kills an existing organism and keeps it dead'. Using 'nuke' seemed worse.
You're wrong that the GPL prohibits one from selling software as software. It doesn't. It does make it harder, because anyone can come in and buy one copy to distribute to everyone else, but this happens very often in the non-open-source world too. Maybe you've heard of pirates?
The only difference is legal ability to sue, but then again when your unwanted re-distributors/pirates are the masses whose real-world identities are hard to discover, this difference doesn't mean that much. You can also gain some (though not all) of the same legal rights to sue unwanted re-distributors by trademarking your application, which forces any re-distributors to have to redistribute under a different name (CentOS instead of RedHat) which puts them at a marketing disadvantage.
Is your example of developing a niche feature for a niche domain really the traditional way? I guess so, but since the GPL has been around there have been numerous examples of what-would-have-been-proprietary features still being developed, released, and open sourced. e.g. if you own all the copyright to a GPL program, some niche domain representative can come along and you can sell them a non-GPL license to develop their addon for which they can then resell. As another e.g., look at all the companies who have contributed to the Linux Kernel. The company wants a particular feature because they can use it to make money for some other reason, so they pay developers to write the code which then gets GPL'd. The company still makes money from the code, the developers make money by writing the code, and the users directly, obviously benefit from the code being there as opposed to the company having estimated indirect guesses at how much value they could capture by selling the code for what the market could bear.
Edit: I do agree with you about the irony, though.
>It is an unfortunate byproduct of GPL like licenses that they poison[1] the market for those specialized tools.
Obviously GPL 'poisons' the market for derivative _proprietary_ tools. The whole idea behind GPL is that the end user should have the right to get the source code. If the only way to charge for your work is through artifical scarcity by hiding the source code then no, you can't do that as a derivative of someone else's GPL licenced code.
If we are talking about your own code, then obviously you can licence it both as GPL and offer it through other agreements aswell. Take x264 for instance, the devs are making good money by offering it through a proprietary licence for those who doesn't want to open their source while making it freely available for open source projects under GPL.
And your copy protection analogy is hypocritical. GPL actually prevents the artificial scarcity employed by copy protection, contrary to the market example you described where someone won't create a GCC plugin because they can't keep it proprietary and thus employ artificial scarcity.
There's no point in arguing against GPL not working with proprietary code given that GPL was created to prevent working with proprietary code. That doesn't mean that you aren't allowed to make money with GPL licenced code, only that you can't do that through A) limiting the number of copies the recipient can make of the software, B) denying the recipient the source code should he/she request it.
Obviously this prevents the most traditional way of making money from software which is through artificial scarcity (except the case of when it's truly _your_ code, then you can offer other agreements apart from GPL as in the case with x264), however other ways of making money off open source has emerged like that of Red Hat.
edit: I do agree though that disallowing plugins is ultimately not the way to go since there's alot of possibilities that they offer (and no, I'm not talking about proprietary plugins of which I couldn't care less) and I'm glad that GCC now has a plugin-architecture.
I don't think they were worried about people making money on GCC (you can sell various services built around it, even proprietary IDEs that call out to it, etc.). They were more worried that it would open the door to GCC becoming no longer all-free: users might find that, like with the Linux kernel before the "no unfree firmware" crusade, they de-facto had to use proprietary modules to get various things working, despite the core being free. The hope of the GCC devs was that by making it a choice of "open-source it and link, or don't come at all", they would push at least a few would've-been-proprietary-modules into becoming free software in order to be able to work with GCC.
Whether it worked or not, I'm not sure. The copyleft strategy's success is a fairly complex game-theory problem that's pretty specific to the costs/benefits/alternatives of each party in each situation. The whole point is to try to force a sort of quid pro quo: you can use my free software as long as you open up yours too. As with any quid-pro-quo proposal, whether the other person accepts depends on a lot of factors.
edit: digging for some examples, I think the D front-end may have been open-sourced as a result of that policy, to give D a second compilation route (besides the official Digital Mars D compiler).
Is there a reason I should care about GCC anymore? Admittedly, I mostly code ObjC on OS X, where GCC is no longer relevant, but LLVM seems to have leapfrogged GCC so dramatically that I'm unsure why I would even care about GCC.
LLVM integrates better with tools, has an amazing static analyzer, and AFAIK generates code that is on average as fast and small as GCC. (I believe who wins depends on the code.)
Is there a reason I should care about LLVM anymore? I mean, I mostly code C and C++ on Linux, where no distros build with LLVM and it isn't yet relevant.
Yawn. LLVM seems nice. When it competes on merit in the big world instead of in a sandbox people will care more I guess. Last I tried building my C++ project with it, it puked on the STL headers.
What makes you think GCC 5.0 tomorrow will be better supported by your current development environment, than LLVM today?
I find the rest of our comment somewhat derogatory towards LLVM and the kind of things you can do with it today, it's already at a point where it provides comparable compatibility and features as the many different GCC versions you'll find on various unix systems. Somehow every time I read something about LLVM here people start to rant about some incompatibility they've seen that GCC doesn't have, as if GCC is the epitome of compilers. From experience I can tell you LLVM shows better compatibility with current GCC versions, than many older GCC versions that are still shipped with some Linux distro's.
Eventually, unless GCC makes a giant leap forwards in all the ways set forth in this article, LLVM is going to replace it, sooner or later. I think that's what the guy above me was about when he asked why GCC is still relevant today.
If LLVM is better supported in the future then great: I'll use it and care about it. It's not. That was my point. GCC is supported, so I (have to) care about it. And I'm not talking out of ignorance here. I try LLVM regularly. Clang++ as of a development snapshot of a few months ago couldn't compile the STL headers shipped with the gcc on Fedora 16 (or 15, don't remember), so it can't compatibly be used for C++ development on my platform.
So no, I don't really "care" about it. Fix the compiler to actually be better for my purposes than what I have before telling me what I should use or care about please. And when you do, I promise I'll join your little cult, OK?
So I guess the best choice is to develop with clang for better error reporting and support tools and do the final production build with gcc for optimizations :)
>What makes you think GCC 5.0 tomorrow will be better supported by your current development environment, than LLVM today?
Define 'current development environment', both at home and at work GCC is the primary development environment for me as far as compilers go, I'm not waiting for GCC 5.0, I am using GCC 4.6 today.
>comparable compatibility
Is a very fuzzy statement, having compiled lots of open source projects under many different compilers there are certainly many projects out there which fails to compile with Clang (but it's certainly making fast progress in compability). Granted most if not all of these packages were written against GCC and some of them may use GCC extensions Clang/LLVM does not yet (or in some cases won't) support or some other quirks which all compilers have in their implementations of different standards.
>Eventually, unless GCC makes a giant leap forwards in all the ways set forth in this article, LLVM is going to replace it, sooner or later. I think that's what the guy above me was about when he asked why GCC is still relevant today.
Been hearing that ever since LLVM (and later Clang) surfaced as an option, I'd say you'll have to set your hopes for 'later' (Clang's been around what? 4 or 5 years now?). Personally I can't see why anyone other than someone with an agenda would want either compiler to disappear, competition means better tools for us end users, no matter which toolchain we prefer.
As for modularization, that has been an ongoing task in GCC long before this particular mailing list discussion, and I think it will continue as it has now in small steps.
I'm not saying I'd like to see GCC disappear. In fact, I still depend on it for all of our C++ stuff. The point I was trying to make is that GCC isn't that much better than LLVM in terms of how well it compiles every bit of valid C++ you throw at it. At least not if you have to compile the same code base across multiple different OS and GCC versions.
LLVM is not as good as GCC in some ways, but evidently better and more future-proof in others. Unless GCC evolves in the same direction as Clang + LLVM, the latter will close the gap sooner or later and basically deprecate GCC. I'm not advocating this should happen, not even predicting it will, just observing GCC is starting to fall behind in exactly the areas that make LLVM so useful.
> Been hearing that ever since LLVM (and later Clang) surfaced as an option, I'd say you'll have to set your hopes for 'later' (Clang's been around what? 4 or 5 years now?)
Well, it already replaced GCC on probably one of the most popular platforms for current development, so you can't say it isn't getting anywhere, can you? It's going to get interesting when we see some kind of Gentoo fork that uses it by default. That would be a good indication it is very nearly mature enough to challenge GCC on all aspects.
>Well, it already replaced GCC on probably one of the most popular platforms for current development
Incidentally the owner of that platform is also the main (sole corporate?) driving force of Clang/LLVM and has a history of wanting to incorporate open source into their proprietary tools which doesn't work with GPL licenced code. In other words saying that Apple is switching to Clang/LLVM makes no bigger point in my opinion than saying that FSF uses GCC.
Apple uses LLVM to drive the very sophisticated auto-completion, static analysis, and error reporting features built into XCode, which are by any standard insanely good. No need to get politics or hidden agenda conspiracy theories along for the ride.
Also, I think you should invest a little time finding out what LLVM is used for besides as the backend for the compiler Apple uses. Apple maybe the only heavyweight driving the development of Clang/LLVM, but it is definitely not the only one using or profiting from it.
I'd say that in 9 out of 10 GCC creates faster code than LLVM/Clang (I see typically 5-10% difference in performance oriented code), add to this that LLVM/Clang lacks strong special optimization strategies like PGO (profile guided optimization) then it's a clear win for GCC. GCC also supports more languages and architectures than Clang which simply mirrors the needs of Apple (ObjC, C, C++). If you are on OSX then yes, there's likely little reason for you to use GCC since OSX ships with a (5 year?) old GCC version and also obviously because Clang/LLVM integrates much better with Apple's proprietary XCode.
That said I use both, and at work we test our code against both toolchains (and some other compilers aswell). The static analyser in Clang is a welcome addition and the error diagnostics/reporting is top notch so it certainly has strong features even though it falls behind GCC in code optimization.
PGO will probably come to LLVM soon, for what it's worth. They added branch probability and basic block frequency support in 3.0 with an eye towards it, anyway.
Great, yes there's been propositions made towards it for quite some time but no actual code so I was almost thinking it wouldn't happen, here's hoping it will happen now. Every other major compiler I can think of has it, GCC, ICC, Open64, MSVC, and the optimization often has a great impact on performance dependant code.
Since 3.0 added greedy register allocation and LLVM SVN just added better intrinsics for SSE and AVX, I've seen LLVM SVN from the last few weeks pull ahead of GCC 4.6.2 in quite a few personal projects for high performance C++ whereas before that, as you say, GCC was pretty much always ahead.
However, GCC 4.7's just around the corner and I haven't tried that yet...
If your only reason for using gcc is speed and you're on a Linux platform, you should really try out icc. The loop unrolling and vector op generation are much better than gcc's (at least for code we've tested on, YMMV) and can result in some really big speedups.
Though, admittedly, if speed is an issue you probably have already manually loop-unrolled and used the gcc compiler intrinsics.
I have and yes ICC generally won on our tests but:
A) it's proprietary, I have no interest in relying on a proprietary toolchain (and from what I gather neither does the company I work for)
B) it supports a very limited range of cpu architectures, not only is it directly tailored for Intel cpu's it even has a history of selecting poor code paths for AMD cpu's.
As for manual loop unrolling, for alot of code PGO does a great job here by unrolling based on the statistics gathered during the first pass. In fact GCC's pgo seems to do a better job than ICC's pgo implementation, ICC's lto beats GCC's on the other hand, and of course ICC does a better job at vectorization and has better optimized math functions.
I'm really happy to see this sort of discussion happening within the GCC project. While LLVM/Clang are nicer and more usable than GCC in a lot of ways, in my experience GCC is still much more mature, generates better code, and has been implementing features new features from C++11 more quickly. I also like that GCC, glibc, and the GNU libstdc++ are all developed together so that as the compiler implements new optimizations and language features, the runtime environment also takes advantages of those features. I've been impressed with the last few GCC releases (I'm already using 4.7 for my own work).
Competition is good, and it's great to see that GCC development is going strong.
Small world, Dave and I just ran into issues related to this a week ago (I suppose it may have motivated his email). Namely that there was no single API to get the assembler generated for an RTL (register-transfer-language, GCC's final IR) node without going through some destructive APIs.
We already have llvm as a c++ monster(hundreds or thousands of MBytes on my mac), witch is modular, and have a more permissive license.
So you are going to risk the only advantages of gcc,(written in c and relatively small and stability), so you could copy the new kid on the block?
If you are going to copy them, copy the more permissive license. It will give commercial companies like Apple the option to improve your software like they do with llvm(Apple hired llvm creator).
I'm guessing he's referring to either the disk space needed to complete a build (~4GB on my machine) or the size of the generated binaries and libraries (304MB on my machine). In either case, I think your point holds that LLVM isn't substantially "larger" in any major sense of the word.
One confounding factor is backends. On one hand, GCC has a lot more of them, which contributes to a larger source base, but shouldn't be considered a disadvantage out of hand. On the other hand, LLVM builds all 13 of its backends into the binaries and libraries by default (compared to GCC's single-backend approach), which contributes to larger installed files but shouldn't be considered a disadvantage out of hand.
As a minor point of order, neither LLVM nor GCC include a linker; they both shell out to the system linker (often GNU ld from binutils). LLVM now has the equivalent of an assembler (direct object code emission) for those backends that support it, and the nascent lld ( https://github.com/chapuni/lld (warning: i couldn't find the webpage in www/ hosted anywhere, this is as close to something canonical as I could find) ) looks to be the beginnings of an LLVM-affiliated linker.
On OS X, you get clang and llvm-gcc in XCode 4.1, which is a solid 1.4 GB download. You're absolutely right about clang being pretty lightweight, so it's getting a bad wrap by association. I'm honestly not sure why XCode is so large: perhaps the IDE and iOS simulator?
46 comments
[ 3.1 ms ] story [ 118 ms ] thread"GCC 5?" http://gcc.gnu.org/ml/gcc/2012-03/msg00256.html "GCC 5 & modularity": http://gcc.gnu.org/ml/gcc/2012-03/msg00263.html
http://lwn.net/Articles/301135/
You can flame over that if you like (but please don't: just google the older flame wars from the 90's, this is depressingly well-travelled ground), but don't get confused over the motivations of the actors. The FSF has been nothing if not crystal clear about their priorities.
The irony is that if folks are trying to check in changes into the GCC tree that allow for plug-in modules because that is what they want, and the community is denying those commits because they fear having a plug-in architecture would enable other people to do bad things. Well that is ironic that such changes would be denied based on a potential transgression for some of the users.
When I read the argument it sounded like what folks had been arguing on the other side back in the 90's, hence the irony.
The whole point of GCC is to have a complete compiler toolchain where all the enhancements are being made available to _all_ end users. Catering for companies who wants a free strong frontend/backend on which to develop their proprietary extensions is obviously NOT what FSF is interested in and I personally agree with their 'ideology' in this case as the last thing I want to see is a situation where developers keep their enhancements proprietary (likely due to the wishes of their companies who see no gain in releasing those enhancements and instead wants to keep those enhancements as a competitive edge).
Also I like how GCC enforces patent protection grants to be given by code contributors, something which LLVM does not and I fear is something which could open a big can of worms later down the road.
Off course, scoffing at the 'ideology' which lead to the creation of the toolchain that is fueling pretty much the entire open source ecosystem not to mention lots of proprietary projects aswell makes you look pretty stupid in my book. Also GPL is obviously a licence through which numerous companies find it agreeable to cooperatively develop code, hence the success of Linux and GCC.
"The whole point of GCC is to have a complete compiler toolchain where all the enhancements are being made available to _all_ end users." ... "the last thing I want to see is a situation where developers keep their enhancements proprietary."
I believe you have correctly expressed a consensus opinion of why it would be 'bad' to allow proprietary plugins. And your claim posits a reason:
"(likely due to the wishes of their companies who see no gain in releasing those enhancements and instead wants to keep those enhancements as a competitive edge)."
Which is also a common reason given.
However what if there was a different reason? What if there is some capability that could be created with a plug-in that is pretty specialized, further that plug-in would require specialized domain knowledge and would only be of use to a small number of GCC users.
Traditionally the way the market has created such things is that a person invests their time to create the capability, and they charge a fraction of what it cost them to others to use the capability. The compute the fraction to offset the cost of developing it, and the community benefits by getting access to this capability for a fraction of what it would cost to develop in house, and the developer benefits by having the cost of their efforts covered by the community.
In a GPL world where the work would be considered derivative, you remove the opportunity for people to charge for their work, and thus you remove the economic motivation for getting something built. This damages the community as a whole with a somewhat 'invisible' "didn't go there" sort of damage (you only miss something if you had it and then you don't, not if you never had it). It is an unfortunate byproduct of GPL like licenses that they poison[1] the market for those specialized tools.
I completely understand the motivation behind the FSF and GCC communities for wanting to keep GCC available for all.
But you have to also note that people who sell software make very much the same arguments in defense of copy protection. They (the software producers) argue that they want everyone to have the same experience and they can't control that experience if people are out there making bootleg copies and changes they don't know about. So they deny something their customers want "software unburdened by loathsome copy protection" to preserve their stated goal of giving everyone the same experience with their software.
So if the FSF and GCC communities are denying something their customers want "modularized GCC tools for easy customization through plug-ins" in order to preserve their stated goal of giving everyone the same experience with their software, well it strikes me as ironic.
[1] Sorry for inflammatory way that sounds, my thesaurus is coming up blank on terms that mean 'something which kills an existing organism and keeps it dead'. Using 'nuke' seemed worse.
The only difference is legal ability to sue, but then again when your unwanted re-distributors/pirates are the masses whose real-world identities are hard to discover, this difference doesn't mean that much. You can also gain some (though not all) of the same legal rights to sue unwanted re-distributors by trademarking your application, which forces any re-distributors to have to redistribute under a different name (CentOS instead of RedHat) which puts them at a marketing disadvantage.
Is your example of developing a niche feature for a niche domain really the traditional way? I guess so, but since the GPL has been around there have been numerous examples of what-would-have-been-proprietary features still being developed, released, and open sourced. e.g. if you own all the copyright to a GPL program, some niche domain representative can come along and you can sell them a non-GPL license to develop their addon for which they can then resell. As another e.g., look at all the companies who have contributed to the Linux Kernel. The company wants a particular feature because they can use it to make money for some other reason, so they pay developers to write the code which then gets GPL'd. The company still makes money from the code, the developers make money by writing the code, and the users directly, obviously benefit from the code being there as opposed to the company having estimated indirect guesses at how much value they could capture by selling the code for what the market could bear.
Edit: I do agree with you about the irony, though.
Obviously GPL 'poisons' the market for derivative _proprietary_ tools. The whole idea behind GPL is that the end user should have the right to get the source code. If the only way to charge for your work is through artifical scarcity by hiding the source code then no, you can't do that as a derivative of someone else's GPL licenced code.
If we are talking about your own code, then obviously you can licence it both as GPL and offer it through other agreements aswell. Take x264 for instance, the devs are making good money by offering it through a proprietary licence for those who doesn't want to open their source while making it freely available for open source projects under GPL.
And your copy protection analogy is hypocritical. GPL actually prevents the artificial scarcity employed by copy protection, contrary to the market example you described where someone won't create a GCC plugin because they can't keep it proprietary and thus employ artificial scarcity.
There's no point in arguing against GPL not working with proprietary code given that GPL was created to prevent working with proprietary code. That doesn't mean that you aren't allowed to make money with GPL licenced code, only that you can't do that through A) limiting the number of copies the recipient can make of the software, B) denying the recipient the source code should he/she request it.
Obviously this prevents the most traditional way of making money from software which is through artificial scarcity (except the case of when it's truly _your_ code, then you can offer other agreements apart from GPL as in the case with x264), however other ways of making money off open source has emerged like that of Red Hat.
edit: I do agree though that disallowing plugins is ultimately not the way to go since there's alot of possibilities that they offer (and no, I'm not talking about proprietary plugins of which I couldn't care less) and I'm glad that GCC now has a plugin-architecture.
Whether it worked or not, I'm not sure. The copyleft strategy's success is a fairly complex game-theory problem that's pretty specific to the costs/benefits/alternatives of each party in each situation. The whole point is to try to force a sort of quid pro quo: you can use my free software as long as you open up yours too. As with any quid-pro-quo proposal, whether the other person accepts depends on a lot of factors.
edit: digging for some examples, I think the D front-end may have been open-sourced as a result of that policy, to give D a second compilation route (besides the official Digital Mars D compiler).
LLVM integrates better with tools, has an amazing static analyzer, and AFAIK generates code that is on average as fast and small as GCC. (I believe who wins depends on the code.)
Yawn. LLVM seems nice. When it competes on merit in the big world instead of in a sandbox people will care more I guess. Last I tried building my C++ project with it, it puked on the STL headers.
Use what you like.
I find the rest of our comment somewhat derogatory towards LLVM and the kind of things you can do with it today, it's already at a point where it provides comparable compatibility and features as the many different GCC versions you'll find on various unix systems. Somehow every time I read something about LLVM here people start to rant about some incompatibility they've seen that GCC doesn't have, as if GCC is the epitome of compilers. From experience I can tell you LLVM shows better compatibility with current GCC versions, than many older GCC versions that are still shipped with some Linux distro's.
Eventually, unless GCC makes a giant leap forwards in all the ways set forth in this article, LLVM is going to replace it, sooner or later. I think that's what the guy above me was about when he asked why GCC is still relevant today.
That said, having a C++ compiler designed for humans and not robots is to be commended.
So no, I don't really "care" about it. Fix the compiler to actually be better for my purposes than what I have before telling me what I should use or care about please. And when you do, I promise I'll join your little cult, OK?
Define 'current development environment', both at home and at work GCC is the primary development environment for me as far as compilers go, I'm not waiting for GCC 5.0, I am using GCC 4.6 today.
>comparable compatibility
Is a very fuzzy statement, having compiled lots of open source projects under many different compilers there are certainly many projects out there which fails to compile with Clang (but it's certainly making fast progress in compability). Granted most if not all of these packages were written against GCC and some of them may use GCC extensions Clang/LLVM does not yet (or in some cases won't) support or some other quirks which all compilers have in their implementations of different standards.
>Eventually, unless GCC makes a giant leap forwards in all the ways set forth in this article, LLVM is going to replace it, sooner or later. I think that's what the guy above me was about when he asked why GCC is still relevant today.
Been hearing that ever since LLVM (and later Clang) surfaced as an option, I'd say you'll have to set your hopes for 'later' (Clang's been around what? 4 or 5 years now?). Personally I can't see why anyone other than someone with an agenda would want either compiler to disappear, competition means better tools for us end users, no matter which toolchain we prefer.
As for modularization, that has been an ongoing task in GCC long before this particular mailing list discussion, and I think it will continue as it has now in small steps.
LLVM is not as good as GCC in some ways, but evidently better and more future-proof in others. Unless GCC evolves in the same direction as Clang + LLVM, the latter will close the gap sooner or later and basically deprecate GCC. I'm not advocating this should happen, not even predicting it will, just observing GCC is starting to fall behind in exactly the areas that make LLVM so useful.
> Been hearing that ever since LLVM (and later Clang) surfaced as an option, I'd say you'll have to set your hopes for 'later' (Clang's been around what? 4 or 5 years now?)
Well, it already replaced GCC on probably one of the most popular platforms for current development, so you can't say it isn't getting anywhere, can you? It's going to get interesting when we see some kind of Gentoo fork that uses it by default. That would be a good indication it is very nearly mature enough to challenge GCC on all aspects.
Incidentally the owner of that platform is also the main (sole corporate?) driving force of Clang/LLVM and has a history of wanting to incorporate open source into their proprietary tools which doesn't work with GPL licenced code. In other words saying that Apple is switching to Clang/LLVM makes no bigger point in my opinion than saying that FSF uses GCC.
Also, I think you should invest a little time finding out what LLVM is used for besides as the backend for the compiler Apple uses. Apple maybe the only heavyweight driving the development of Clang/LLVM, but it is definitely not the only one using or profiting from it.
LLVM is where the innovative ecosystem lives now, even if GCC is more reliable for just churning out fast C code.
That said I use both, and at work we test our code against both toolchains (and some other compilers aswell). The static analyser in Clang is a welcome addition and the error diagnostics/reporting is top notch so it certainly has strong features even though it falls behind GCC in code optimization.
However, GCC 4.7's just around the corner and I haven't tried that yet...
Though, admittedly, if speed is an issue you probably have already manually loop-unrolled and used the gcc compiler intrinsics.
A) it's proprietary, I have no interest in relying on a proprietary toolchain (and from what I gather neither does the company I work for)
B) it supports a very limited range of cpu architectures, not only is it directly tailored for Intel cpu's it even has a history of selecting poor code paths for AMD cpu's.
As for manual loop unrolling, for alot of code PGO does a great job here by unrolling based on the statistics gathered during the first pass. In fact GCC's pgo seems to do a better job than ICC's pgo implementation, ICC's lto beats GCC's on the other hand, and of course ICC does a better job at vectorization and has better optimized math functions.
Competition is good, and it's great to see that GCC development is going strong.
We already have llvm as a c++ monster(hundreds or thousands of MBytes on my mac), witch is modular, and have a more permissive license.
So you are going to risk the only advantages of gcc,(written in c and relatively small and stability), so you could copy the new kid on the block?
If you are going to copy them, copy the more permissive license. It will give commercial companies like Apple the option to improve your software like they do with llvm(Apple hired llvm creator).
LLVM + Clang source code: 9.9MB + 6MB = C, C++ and Obj-C compiler and linker
GCC source = 69MB = just C compiler and linker
G++ source = 6.6MB = C++ additions to GCC
So I'm curious as to where you're getting the "hundreds or thousands of MBytes on my mac" from.
One confounding factor is backends. On one hand, GCC has a lot more of them, which contributes to a larger source base, but shouldn't be considered a disadvantage out of hand. On the other hand, LLVM builds all 13 of its backends into the binaries and libraries by default (compared to GCC's single-backend approach), which contributes to larger installed files but shouldn't be considered a disadvantage out of hand.
As a minor point of order, neither LLVM nor GCC include a linker; they both shell out to the system linker (often GNU ld from binutils). LLVM now has the equivalent of an assembler (direct object code emission) for those backends that support it, and the nascent lld ( https://github.com/chapuni/lld (warning: i couldn't find the webpage in www/ hosted anywhere, this is as close to something canonical as I could find) ) looks to be the beginnings of an LLVM-affiliated linker.
This is perfect; the actual idiom is 'bad rap' but this actually makes more sense in context. ;)
Making the project more modular, while not a bad idea in itself, could potentially delay the implementation of the latest standards.
https://fedorahosted.org/gcc-python-plugin/