Someone want to give (or link to) a brief rundown of the advantages/disadvantages?
Someone want to give (or link to) a brief rundown of the advantages/disadvantages?
http://clang.llvm.org/comparison.html#gcc
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.
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.
Here [0] is an example of Xcode leveraging clang to provide valuable feedback. The second picture speaks volumes.
[0] http://www.macfanatic.net/blog/2009/08/28/xcode-3-2-static-a...
I'm not sure how it works in Clang, but of course, GCC doesn't "see" macros, this is seen by the CPP (C pre processor) and GCC operates in C code only
There's a flag (-E) that makes GCC output the preprocessed code and stop
Faster compile times.
Better error messages.
BSD license.(More in line with their project not a judgement on my part.)
Designed to make use in tools easier.
Cons:
Code produced isn't as fast, but not much slower.
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.
[1] http://gcc.gnu.org/ml/gcc/2012-02/msg00134.html (probably unbiased) and http://clang.llvm.org/performance.html (probably biased)
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.
Performance-wise though I still generally get ~5-15% better speed on generated code with GCC (corei7).
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.
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).
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"