I have been working on getting a quite complex C++ code base (3M+ LOC) with heavy template use to compile on clang. Along the way, I have found many violations of the C++ standard that GCC silently accepts, several obscure GCC features that clang does not support, and up to now filed three clang bug reports.
The project compiles now, but the resulting executable is still not passing basic regression tests :)
I think our codebase has been depending for too long on just one compiler, and clang C++ support isn't perfect yet. (FreeBSD has mostly C code which is very stable). I will keep pushing to get it all working :)
> It's been very frustrating because we're well past the point where refactoring-out Boost would be cost effective.
I'm curious: What was the motivation for switching in the first place? And why is staying with the proven tool not the better option?
My own case: It makes no sense to migrate our (relatively small by the sound of it) codebase. It is in production, generating money, and anything that interferes with that is simply not going to be considered. Our largest dependencies are wxWidgets, ffmpeg, libcurl: It has performed well, though not without some hiccups.
We have been using clang on Apple, Linus, and FreeBSD. It's a lot nicer to work with and compiles faster than GCC, including 4.7. As people point out, the generated code is on average a little slower.
Linus' ultimate plan for Linux. Replace brain with Linux. Circle complete. Spleen still uses binary blob for driver. Open-source attempt to recreate it called Splouveau.
Outside the license, the main benefit seems to be that in Clang the different stages are less intertwined than GCC. This is supposed to make developing Clang easier (since you don't have to understand so much), allowing optimizations to be tested and added easier.
On the user side, Clang is well known for providing much better error messages. Some error messages will even suggest possible fixes (you might get something like "Can't assign a pointer to a something, did you mean *pointer?").
The GCC guys have been improving their compiler for a long time, and over the last few years they have been working hard to make GCC easier to work on and optimize. I believe that GCC is usually faster or the binaries are smaller by a few percent, but it's not generally a drastic difference.
GCC speedup is actually quite substantial in math/numerical code (which, in turn, is not as fast as Intel's ICC). Moreover, GCC supports OpenMP, whereas Clang does not. This alone make building several scientific software packages not possible with Clang.
It's important to note though that it has only been recently (starting with GCC 4.4) that I've started to see some _improvement_ over previous GCC versions. GCC 3.x was known to be bloated, buggy and emit poor code for almost every architecture. Open64 was superior in _all_ regargs up to GCC 4.2/4.3 in my opinion.
Clearly, the whole project greatly benefited from Clang's competition.
Agreed. Competition is GREAT, and seeing these two excellent open source compiler offerings engaging in friendly competition means we as end users all benefit, no matter which solution we prefer (or use both, as I assume I'm not the only one doing).
Starting with gcc 4.7 and 4.8 the error message for C++ are also improved [1] and start to get close to clang. The competitions seems to be good for gcc and I like to have the choice between two compilers.
> On the user side, Clang is well known for providing much better error messages. Some error messages will even suggest possible fixes (you might get something like "Can't assign a pointer to a something, did you mean pointer?").*
Here [0] is an example of Xcode leveraging clang to provide valuable feedback. The second picture speaks volumes.
While we're on the subject of static analysis and valuable feedback, you should take a look at PVS-Studio, which is pretty neat as well, and is comparable to what clang can do (as far as I can tell from their blog posts).
On error report: I wrote some programs in C that heavily reply on huge macros to mimic template in C++. The gcc error report is completely useless as it points to the line with the entire function expanded to a single line. Clang is much more clever.
I do not know how clang achieves that, either. BTW, with gcc, I usually do something like this: "gcc -E prog.c | grep -v ^# | indent > prog-fmt.c" This is quite clumsy, though.
I thought Firefox was seeing speedups from using Clang generated code? I guess I don't know the average case of course, but I'm curious to hear more about this, my Clang/LLVM-fu is weak
Well you are likely thinking of Raphael Espindola's tests of using Clang to build Firefox, and those tests showed that Clang/LLVM was better in some instances but overall GCC was faster.
HOWEVER the GCC he tested against was GCC 4.2, a ~5 year old version of GCC which is the version OSX ships with (he was using OSX) so the tests as comparative between GCC and Clang/LLVM of today were pointless.
It should also be noted that Firefox as used on people's machines today gets a large performance boost from profile-guided-optimization (remember back when people noticed that win32 Firefox under wine was faster than native Firefox on Linux? This was because of the Linux versions not being compiled with profile-guided-optimization at the time), and this optimization is not available for Clang/LLVM (though iirc there's a GSOC project for it this summer).
One area where Clang really shines is compile time - it's faster than gcc, at least a little [1].
The claims about who has faster binaries are pretty difficult to judge - it seems they really are about equal. It may be highly superscalar CPUs with instruction reordering and register aliasing hide the difference.
My code consists of tight loops used for numerical simulation. Clang runs about 2x slower. Hence I conclude that Clang is bad for optimizing tight loops.
Many of the Clang vs. GCC tests are clandestinely skewed towards llvm because they involve code that does not benefit from low level optimization.
Many of the people who work on GCC are scientists who want tight loop performance while many of the folks who work on clang want a BSD license.
It depends a lot on the use-case. For my hobby project (numerical stuff, C++) I got a speedup of more than 10% by moving to Clang. Huge stuff. I spend ~50% of my time in one hot function, though, and it's entirely possible that GCC generated better code for the rest of the project.
As usual, the only reliable way to know which compiler generates better code for your program is to run benchmarks.
For what it's worth, I wasn't blown away by the compile times or error messages when I moved to Clang. I think GCC is getting a lot better, but I'd also learned to live with its failings regardless.
For me it's mainly the error messages, either Clang/LLVM has gotten slower in compiling or GCC has gotten faster, but it's not a big 'percieved' difference for me anymore. I think the Clang error messages are more informative and also that the colored output makes it easier to read.
Performance-wise though I still generally get ~5-15% better speed on generated code with GCC (corei7).
A:
Modular design. You can change everything, modify to make your own compiler and even include on a proprietary project if you want(license much more permissive than GPL)).
It lets you interpret C and C++, if you want.
It lets you compile in C, C++ to bytecode like java if you want, native code if you want too.
It can compile JIT fast things like OpenCL or javascript.
D: It is huge for a compiler. I believe gigabytes or so.
"One of our main goals for GCC is to prevent any parts of it from being used together with non-free software. Thus, we have deliberately avoided many things that might possibly have the effect of facilitating such usage"
If you want a more technical review of LLVM, I think this is a very good one: http://www.aosabook.org/en/llvm.html (Chris Lattner is the creator of LLVM)
I'm excited about this change. I was working on a C++ project last summer that had a lot of templates. Clang was a lot faster, and a lot easier to use.
Aren't they pretty much doing anything these days to make it easier for Apple to “steal” their code, considering that most consumers of BSD code are Apple users?
As someone who tends to release on more-permissive licenses, I just want to clarify the causal model here.
It's not "doing something extra" to release with BSD; the "doing something extra" comes when you want to properly release with GNU.
After a long random walk over the licensing attitudes graph, I have found myself for the last several years stably located at one node. This node is, "licensing is about lawsuits." People often release with the GNU GPL because licensing, for them, is not about lawsuits but has some other import and use -- perhaps moral. But for me, a license is strictly about defining what sorts of lawsuits are possible.
Copyleft is a threat to sue. More precisely, it is the threat "I may sue you if you don't threaten to sue others." And that just sounds crazy. Why would you do that? Well, the stated goal of copyleft is to eliminate all fears of lawsuits by using legal threats.
Let me hasten to add that this is a very pretty idea. If you know the religions of India, this idea is called tantra -- that sometimes the most precise tool for removing a thorn is other thorns, or sometimes the best way to remove dirt from your clothes is with an abrasive substance -- like other (cleaner) dirt. The reason that Stallman is sometimes described as religious may come back to the attendant mysticism that tantric approaches usually bring with them.
My point is, this sort of thinking is an active choice and requires you to enforce the threat, at least in principle. The BSD license is much simpler: it says "I won't sue you, and you're not allowed to sue me." It is a Buddhist-nonviolence approach to eliminating lawsuits: "I have stopped causing suffering in this world, Angulimala -- now why don't you stop?"
It is nothing extra to release this way: you simply promise to not sue anyone, and you only give permission conditional on the fact that they will not sue you, you write it once and then it is done. It's clean and elegant. If you want to actually be a productive GPL licenser, you have to either hope that the threat in the docs is enough, or else find everybody who is "conveying" your software, and slap them with a lawsuit so that they learn how much lawsuits suck.
Hmmm... no I have to disagree with the picture you paint here. A licence is not a 'threat to sue', it's a set of conditions for use. Theoretically you could be sued for removing the copyright notice and author attribution from BSD licenced code just as you could be sued for not making the source code available when you distribute GPL licenced code.
Furthermore when you talk about 'promising not to sue', as we see today the highest risk of being sued for software is through software patents. GPL says that if you distribute your patented code under GPL you are not allowed to turn around and sue people using that code or any derivates of it. The BSD licence makes no such provisions and as such you could release patented code under BSD and the proceed to sue people using it.
I love your comparison gpl and bsd licenses to different religions/philsophical ways of dealing with violence.
However, the game theoretic consequences of absolute non-violence (as in Jainism) are negative, unless non-violence is adhered to by everyone in the neighborhood. Or, I suppose you could say instead that non-violence is not a principle to be taken alone. In order to be effective and safe, you have to divest yourself of anything worth stealing, avoid creating interpersonal problems, and stay out of environments where you might be caught up in unrelated violence.
Since copyright has no meaning in isolated or pure environments like that, the analogy breaks down. Copyright is fundamentally a social and legal construct, not a philosophical one.
It's not quite accurate to draw the comparison with a 2-clause BSD license though. Relinquishing copyright and placing code into the public domain would be more pure. Authors licensing code under a 2-clause BSD license are threatening to sue if proper attribution is not kept. 3 and 4 clauses licenses add more promises to sue under some conditions.
This is a lovely way of explaining the difference, and it'll be what I link people to in future when explaining why I opt for BSD-style licensing. Thank you.
As lovely as the explanation may be, it focuses on a single issue. The whole point of the GPL is granting and protecting end-user rights - protecting the developer from lawsuits is a secondary concern.
The end-user is not the developer who re-uses GPL'd code, but the guy who uses the final program.
By licensing code under the GPL, you grant the end-user the right to use and modify any program using your code as he sees fit (as long as he adheres to the rules of the GPL on re-distribution), and no intermediate developer can legally take that right away.
Of course this restricts the freedom of indermediate developers, but the GPL is intentionally -Ouser, not -Odeveloper. It just so happens that some users are also developers.
> What end-user rights does the GPL grant or protect that the BSD license doesn't?
The right to receive a copy of the implementation of the program they are using and re-distribute it freely.
I say "right" here, because in the case of BSD source on the internet it could be more accurately coined an "election" to distribute the source. As you say, "whatever the hell you want." Which is fine. So is requiring copies to carry a complete copy, including the human-readable form, and the rights to redistribute those, ala GPL.
I think viewing licenses as just about lawsuits is a reductionist take on the issue.
A license can provide a strong indication of your wishes even if you don't ever intend to sue. I don't think it "requires you to enforce the threat" to be effective as a signal to others, particularly companies.
Now, you could say putting a note that isn't part of the license would have the same effect, but I find that hard to believe.
If by steal you mean hiring the best contributors to the project(like Cris Lattner), and releasing a big part of that work freely, then yes, they are letting Apple steal them blatantly.
Wheres the "WHAT?!". The BSD guys have gone on record multiple times saying that they think that RMS and GNU are a joke. It seems natural that they would try and phase out GNU when possible in light of this belief.
Hm. That example is entertaining and creative, but not really consistent with the actual viewpoints of the FSF[0].
Choice statement:
> Distributing free software is an opportunity to raise funds for development.
> Don't waste it!
Redhat is a good example of a company doing well distributing free software and making money doing it; it's just that the typical shrink-wrap license business model doesn't fare so well when copying and modifying the distributed program is allowed and protected.
Also, I don't mean to implicate that you share beliefs with the OpenBSD people, since you are merely reporting on their position -- accurately, in my mind. But I thought this is an interesting bit of related information for the discussion.
FreeBSD is pretty much neutral on the GPL, but BSD licensed software is sort of their "thing", so it's natural they'd prefer a BSD licensed compiler.
NetBSD used to be pretty hostile until control was wrested from wasabi systems which disliked the GPL because it prevented them from closing down GPL software.
Dragonfly never really took a position, so it's safe to assume they're neutral too.
That leaves only the OpenBSD guys, of whom (some of) the vocal part thinks anything not OpenBSD is a joke.
I think that's a bit more of a qualifier than "The BSD guys", most of which don't particularly care about phasing out GNU (even though that happens when accumulating BSD licensed software in their OS), some of which are sympathetic but simply like BSD systems more, and what seems to be a fringe minority which is actually hostile for one reason or another.
>Richard felt that this "ports tree" of ours made OpenBSD non-free. He came to our mailing lists and lectured to us specifically, yet he said nothing to the many other vendors who do the same; many of them donate to the FSF and perhaps that has something to do with it.
Stallman and the FSF apply the same standard everywhere. He rejects Red Hat (a major GNU sponsor) as "non-free" just like OpenBSD, in contrast to what the BSD guys claim.
>Richard has personally made sure that all the official GNU software -- including Emacs -- compiles and runs on Windows.
What?! Most official GNU software does NOT run on Windows.
">Richard felt that this "ports tree" of ours made OpenBSD non-free. He came to our mailing lists and lectured to us specifically"
to complement this story a little. rms had heard from one source or another that OpenBSD was "completely free" too (probably based on their hard and much appreciated work on wifi drivers and blobs), and looked into the matter to see if it could be included in the list of FSF endorsed operating systems (which thus far have only GNU/Linux systems).
He found references to non-free software in the ports tree and wrote to the openbsd mailing list to ask for clarifications.
There were actually a few saner voices who politely stated that was the intent and that OpenBSD as a project had a different definition of "free" and as such should not be included in the officially endorsed FSF-list.
Of course, for the less stable elements, it was a good pretext to scoff and insult the the man. Some even riled on and created a song about it. OpenBSD is a fine operating system, but for a normal person the culture around it can be quiteoffputting.
For bonus points, in the actual recording they note that Hypocrites "Smells like thousand year old goat cheese.". which no doubt refers to Stallmans's legendary hygienic practices. [0]
Yea, most BSD guys I know are also fans of Apple; iOS and Macs on desktop rather than GNU or Linux and Clang is supported by Apple for license reasons.
The project compiles now, but the resulting executable is still not passing basic regression tests :)
I think our codebase has been depending for too long on just one compiler, and clang C++ support isn't perfect yet. (FreeBSD has mostly C code which is very stable). I will keep pushing to get it all working :)