GCC 4.6/4.7 vs. LLVM-Clang 3.0/3.1 Compilers

[jayrulez]

Google, Facebook, Red Hat, VMware, Cray, etc. etc. all employ far more Clang/LLVM developers than Apple does. They will keep it open. I'm at a C++ SG meeting hosted by Microsoft, and I heard from Chandler Carruth (Google) that the LLVM community are getting LLVM/Clamg moved to be managed by its own non-profit, so community direction and ownership should cease to be anything but a straw man hypothetical soon. It'll be no different than fearing that Apache might turn proprietary tomorrow.

So far as "why Clang," the answer continues to be "tools". GCC is all but useless for IDE code completion and custom static analysis, and is outright completely useless for automated refactoring and code transformations, as GCC intentionally lacks the necessary information in its AST.

GCC is also difficult to hack on, which is why so many people who want to work on compilers for fun have jumped on the Clang train. GCC works very well, yes, but only because there is a small core of very dedicated folks who've spent a decade or more accumulating knowledge on the code base. GCC may even be at greater risk of disappearing when you rely on it, because the project has a large "bus factor": too much of its success is dependent on a small number of very difficult to replace people. Clang is easy to jump into and hence getting new people up to expert levels on its internals is much much easier.

Thank you elanthis. I understand this. However, my question was an hypothetical "if" which I would still like a factual answer for. I'm not afraid llvm-clang will be taken one day and I highly doubt it will be. I Just want to understand what would be possible "if" it does.

[vertexSymphony]

Say Apple for some reason makes clang proprietary, can the open source community not fork and continue to develop the last open source version of clang before it became proprietary?

They can't "make clang proprietary". they can take the code, re-license and start a privative fork off that ... but in that case the code of clang would still be open and the community can keep the work with it.
GPL doesn't give any *absoluto* warranty about privative abuse (as some people want you to think), we had PLENTY of examples of that even in the kernel itself (if we put it that way). so this is nonsense, lot's of BSD-licensed projects may be forked or re-used partially, but the original project is still open ... so no, it doesn't threaten in any way the FOSS community. but as I said in the previous thread: licensing is a hard topic, the BSD is a license that is hard to pick where to use. in some cases it's a better choice than GPL, sometimes it's the other way.

It's not a black or white thing, it's a topic with much more colors.

Regards.

P.S → Here's an article I cited in the previous thread that I would like to link again : http://www.theregister.co.uk/2011/05...rs_and_takers/

[jayrulez]

They can't "make clang proprietary". they can take the code, re-license and start a privative fork off that ... but in that case the code of clang would still be open and the community can keep the work with it.
GPL doesn't give any *absoluto* warranty about privative abuse (as some people want you to think), we had PLENTY of examples of that even in the kernel itself (if we put it that way). so this is nonsense, lot's of BSD-licensed projects may be forked or re-used partially, but the original project is still open ... so no, it doesn't threaten in any way the FOSS community. but as I said in the previous thread: licensing is a hard topic, the BSD is a license that is hard to pick where to use. in some cases it's a better choice than GPL, sometimes it's the other way.

It's not a black or white thing, it's a topic with much more colors.

Regards.

P.S → Here's an article I cited in the previous thread that I would like to link again : http://www.theregister.co.uk/2011/05...rs_and_takers/

Thanks for your reply and explanation. I was simply baffled that every time something is posted about llvm and or clang there is a subset of users here who always express negatively towards it. I believe everyone has the right to prefer a particular licence, but given your explanation, to me the zeal of some of these members is borderline irrational. If there is no way that Apple or any other company can simply deprive one of the use or sources of llvm and clang, then there is no need for rejecting the project.

On the other hand, improvements to clang can only serve to make gcc better. Theoretically, given the licences, gcc can use code from llvm and clang. If what they fear is that people will start a mass migration from gcc to clang and cause clang to stagnate, then clang would not be at fault, but gcc for not providing improvements to be more usable to developers.

I understand there are people who will choose a compiler based on the licence, but they are the minority. The majority of people will simply use the best tool for the job be it clang or gcc or any other compiler.

So there does not need to be a religious war among compilers because of licences.

[joshuapurcell]

I can understand why many people would be completely turned off from a topic as soon as a related but unfamiliar and polarizing side of the topic gets brought up. On one hand the LLVM project is doing some things right in the compiler area. Elanthis' post on the merits of this project is the best in this thread at explaining LLVM/Clang's strengths. In spite of the relatively unimpressive benchmarks it showed in this article relative to GCC, it did manage to stay close to GCC performance and this new tool does have some features that make it easier to use for those who are unfamiliar with GCC.

That being said, it is impossible to cover the topic of free and open source software without also covering the important related topic of licensing. Ignoring the licensing issue actually does a disservice to free software software in general, because without the type of FOSS licensing we now have we would not have a free software community to begin with. Not only that, but the idea of free software itself is being attacked more now than at any time in the past with all the patent-related legal issues and challenges being raised. If the people who benefit from and contribute to the free software community don't take a healthy and vocal approach to licensing (which needs to be done in order to continue the existence of our community) then who will? There will always be lawyers and others who will do so for a fee, but they will only be around so long as there is money to pay them.

This is one area where the differences between BSD and GPL arise. It should be no wonder that the BSD license is the preferred licence for companies who contribute to open source. The reason for this is simple: these organizations want to reserve the right to at any time take a replica of the open source project they have contributed to and then only contribute their changes and improvements to their walled-off version of the project. What is lost in this process is the fact that their new changes and benefits are made possible by (and exist only because of) the open source project they have taken from. In short, these organizations that operate in this manner take much more than they give back to the project. Many organizations see BSD-licenced projects merely as a free resource, and they see the developers who contribute to those projects as little more than free labor to benefit from. These organizations have no interest in contributing to the project to the same extent that they plan to gain from the project. BSD-style licenses allow this to occur much more so than GPL-style licenses. The GPL (and other similar licenses) ensure reciprocity to a much greater extent given our current legal reality.

On a side note, sometimes you hear people complaining about the complexity of the GPL in relation to other open-source licenses. But this is not a fault of the GPL itself. This perceived complexity is the result of working within our society's current legal framework to ensure a certain level of reciprocity continues to be apart of any free software contribution that is GPL licensed.

These licensing issues are easily overlooked by many people who enjoy free software. It is natural to instead focus on learning new skills from these projects and pointing out the achievements (in technical functionality, organization and project management) of some projects over others. After all, many people who are interested in open source come from a technical or educational background (as opposed to a legal or humanitarian background). But the legal and social ramifications of free software don't go away (and are not made any less important) by choosing not to focus on those key issues. In fact, it is many times just the opposite.

[vertexSymphony]

Thanks for your reply and explanation. I was simply baffled that every time something is posted about llvm and or clang there is a subset of users here who always express negatively towards it. I believe everyone has the right to prefer a particular licence, but given your explanation, to me the zeal of some of these members is borderline irrational. If there is no way that Apple or any other company can simply deprive one of the use or sources of llvm and clang, then there is no need for rejecting the project.

On the other hand, improvements to clang can only serve to make gcc better. Theoretically, given the licences, gcc can use code from llvm and clang. If what they fear is that people will start a mass migration from gcc to clang and cause clang to stagnate, then clang would not be at fault, but gcc for not providing improvements to be more usable to developers.

I understand there are people who will choose a compiler based on the licence, but they are the minority. The majority of people will simply use the best tool for the job be it clang or gcc or any other compiler.

So there does not need to be a religious war among compilers because of licences.

Think that this is very symbolical, that's why some GNU soldiers are sensitive about this ... if GCC is obsolete and replaced by Clang, it would mean less % of "GNU" in "GNU/Linux" until we find that we don't actually have to call the system GNU/Linux if we can ship a system that is GNU-free (people at FreeBSD camp is working hard on this ... mostly because they don't feel good about shipping GPLv3 code - and that's why they use gcc 4.2 atm, the last gplv2 version of gcc-, that very own technical differences with clang thing damaged GCC a lot )

And yes, they can't deny anyone the use of open BSD licensed code, as long as no patents are involved, same situation as GPLv2 ... GPLv3 is whole another story because it cover patents but also adds some more differences that you may or may not wish.
people at GNU can take code (if they want) from Clang, basically because BSD and MIT are compatible with GPL ... but it doesn't work the other way.

They pretty much get anal with the idea of a company making a privative fork (stuff allowed by the license, consciously chosen by the developer ), make money off that and not giving back code !! (stuff that GPL requires, but can be circumvented in some ways) but this whole idea requires an analysis on it's own, because we usually comfort ourselves with short-sighted reasoning without asking more stuff like if the company would not give code anyways by ignoring the GPL-licensed code !! (happens, ask yourselves why some liberally-licensed projects exists in the first place ... in fact, that's the reason of why GPLv3 code is being keeped FAR away from FreeBSD base code).

I don't say they are wrong, but they don't show the entire picture, the arguments are partial and the words they choose leaves a lot to be desired (for example, they talk about "closing code" which suggests that existing free and open code, with his open source community and governance stops existing in a second, wich is ridiculous ... because that doesn't happen when you fork ). The idea is to know the consequences of a licensing (your rights and your obligations) and think about future without bad information like GNU zealots *tend* to spread and move on what best suits your needs.

And yes, the licenses war are nonsense, like programming language wars and such ... people forget that these are tools and that you use the right tool for the job. you don't make religions about tools and you don't use the same tool for every job !!!

Sorry if this post is messy, it's terribly late in here.

[XorEaxEax]

There's alot of 'they' in your post, I find these generalizations do nothing but harm and with terms like 'GNU-soldiers' it shows you are just another partisan pointing fingers.

I don't say they are wrong, but they don't show the entire picture, the arguments are partial and the words they choose leaves a lot to be desired

Well neither to do you. There's a practical part to these licences which overshadow the GNU or BSD-zelotry. In GPL you are legally bound to release enhancements made to the source code should you ship it in binary form, this has a _practical_impact which is that someone who releases his source code under GPL is then as an end user be entitled to the enhancements made to his code. This is not the case with BSD, it of course doesn't preclude companies from releasing source code but there is no legal incentive, and if the code in question gives them an edge against competitors it's unlikely that they will release it, particularly since there's no reason to expect their competitors to do the same with their enhancements.

Here GPL works great, all participants are legally bound to share their code enhancements as long as they want to option to ship binaries of said software, Linux and GCC has a huge amount of companies cooperatively developing these projects under GPL which underlines how well this works. There's no need for these companies to 'hope' the other company will do right by them, it's in the licence terms. In this respect GPL levels the playing field of it's participants.

This works great for me as an end user aswell, I get to reap the benefits of all these enhancements and again that has a very practical impact.

So looking at LLVM/Clang and GCC, yes barring GCC's maturity which in turn leads to it having stronger optimization and compability/architecture/language support, LLVM/Clang is indeed better from a technical standpoint. It's more modular, built on a newer codebase and offers solutions which GCC at the moment (and not in the foreseeable future) does.

So with that in mind I'm really glad Clang/LLVM exists, it improves open source compiler technology and also helps fill gaps which GCC doesn't cover. However due to it's permissive licencing it lacks some of the practical benefits I as an end user find in GPL-licenced software, which is that there's no reason to expect all enhancements to be contributed back to the project. And having Apple (atleast up until now) as the main driving force behind it certainly doesn't quell those fears for me. That said I'm glad seeing Google recently throwing their weight behind LLVM/Clang as they do with GCC as they are a company which have a track record of wanting to contribute back.

If companies keep on contributing their enhancements back to Clang/LLVM then the licencing doesn't really matter at all, but there's nothing requiring them to do so and if they think their enhancements can give them an edge on the competition and there's no legal reason for them to contribute these enhancements back then there's a good chance they won't, which in turn means the open source version will be inferior or duplication of effort will be required to bring it to par.

Again, these are all _practical_ reasonings, not about GNU or how proprietary code is immoral or some such, and while I think Clang/LLVM offers up a great alternative to GCC, GCC will remain my primary toolchain (or at worst fallback toolchain should Clang/LLVM rapidly improve greatly) simply because it gives me the practical benefit of recieveing all enhancements made to it, something which I can't be sure Clang/LLVM will offer come tomorrow, though the increased support from Google and the non-profit community management thing elanthis mentioned certainly does help.

[kraftman]

Except that GPL is a vested interest in itself.

GCC codebase is a mess and poorly documented. LLVM is clean and well documented. That's why clang is exciting.

Code base and documentation don't compile your code. That's why it's not so interesting.

[kraftman]

This is one area where the differences between BSD and GPL arise. It should be no wonder that the BSD license is the preferred licence for companies who contribute to open source.

This has no reflect in reality. In contrary EkoPath was released under GPL. Most companies contribute to GPL projects - Linux kernel, GCC.

[hoohoo]

More compilers is better compilers. One of the bunch will be fastest at any given thing. That's just the way it is.

[hoohoo]

Also there is things like this: http://www.phoronix.com/scan.php?pag...tem&px=MTA5OTU.

AFIAK GCC does not target GPUS (yet).