I tried a svn build of clang++ two months ago on our in-house code base of hundreds of thousands of lines of C++. I didn't see much advantage to using it.

- I felt misled by all the advertising on the website. They are comparing to Apple's version of gcc-4.2. The last GNU release of gcc-4.2 was two and a half years ago. Even Debian stable has something newer. Compared to gcc-4.2, the newer gcc-4.5 compiles faster, produces faster code, and gives better diagnostics. The comparison on the website was not useful for me to predict the differences now.

- In terms of compile speed, clang was sometimes faster and sometimes slower than gcc-4.5, but overall the differences were very minor.

- In terms of performance, clang was >10% slower, which is OK for debugging builds.

- The diagnostics were a little prettier than gcc-4.5's, but not a huge improvement. I think it was mostly because they were in color.

- Getting the existing codebase to compile was a chore. gcc bends the rules of the C++ standard in some ways that don't appear to cause confusion but make the code more pleasant. For example, it allows unqualified lookup into dependent bases of class templates, which means you can write "foo()" instead of "this->foo()" in things that look like class members (see http://clang.llvm.org/compatibility.html#dep_lookup_bases). There are a number of these - look through the page. I felt like clang was being inappropriately pedantic and beating me over the head with the standard. The most frustrating part was that the compiler wasn't confused - the error message gave me a copy/paste set of changes to make.

- On my Debian system, I could not find a set of c++0x headers that clang knew how to compile (the official instructions say "use gcc's"), so I couldn't try out the new standard.

Just FYI: The reason they're using gcc-4.2 comparisons is that Apple employees are banned from using GPLv3 software. E.g. if you report a bug to them that requires checking out a newer version of GCC they'll just shrug and say "sorry, but we can't try it out".

Oh, and the diagnostics are much better, and not just because they're in color. Consider e.g. this program:

    #include <stdio.h>
    
    int main(void)
    {
        printf("hello %d", "world");
        return 0;
    }

GCC will give you:

    hello.c: In function ‘main’:
    hello.c:5: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘char *’

While clang gives you:

    hello.c:5:20: warning: conversion specifies type 'int' but the argument has type 'char *' [-Wformat]
        printf("hello %d", "world");
                      ~^   ~~~~~~~

Clang tells you not only the line that had the error but also the column, then it higlights the %d format argument, and shows you which argument you gave doesn't fit with it.

Pretty much all of its diagnostics messages are like that. While you sometimes have to stare at code for 5-10 seconds to see what GCC is complaining about clang will tell you exactly what the problem is.

"The diagnostics were a little prettier than gcc-4.5's, but not a huge improvement." <- I think this example fits with this description: gcc clearly stated it was the second argument... it is nice that it pointed out to me what the second argument is, but I can count. A little prettier, but not a drastic improvement.

I think what most of us are really looking when someone claims that they have better diagnostics is to do something for cases that are currently incomprehensible. As an example: if you run into an error in a recursive template, sometimes you are scratching your head at an error that seems to have no direct semantic meaning. When I was really doing a lot of C++, I started to accumulate a mental map of "when gcc claims that X has occurred, what that really means is that I should try explicitly adding a template or typename keyword to a nearby expression".

I've seen people new to C struggle with what I think are relatively simple GCC diagnostic messages. I think they're somewhat simple now since I'm used to them and know C.

But pointing out exactly the bit of code that's wrong, and often what you should do about it is - I think - a huge improvement.

I think that you'd see better the difference in c++ template instantiation error reports

I've been using clang 2.7 instead of GCC for a few months now. I'm never going back to GCC:

* It has much better diagnostics messages: http://clang.llvm.org/diagnostics.html

* Compilation times are much faster, even though I always wrap gcc/clang with ccache.

* It uses a lot less CPU / memory on equivalent compile options.

The only disadvantage is that compared to GCC 4.4 the resulting binaries are usually around 5-10% slower. The LLVM developers say that's to be expected, currently they're targeting GCC 4.2 for their performance metrics.

Why is GCC better? It's probably not that easy to answer, but does GCC have a better register allocator? Better IL optimizations? Better code generation?

This seems like an argument to use LLVM for day-to-day development and gcc for later staging and deployment, not to ditch gcc entirely for LLVM.

Right, I should have mentioned that I only do C development, not packaging. So I compile everything with CFLAGS="-O0 -ggdb3".

But of course if you're producing binary packages you may want to use other criteria than compilation speed and diagnostic messages to select the compiler.

This post seems quite disingenuous. Clang is way cool and a breath of fresh air, but TFA only mentions compile times and at no point does it mention the characteristics of the output binary (size, performances). It also omits the compilation options (the optimization levels would be a pretty good start).

Because it's fast and pretty small, Clang is probably the best thing you can use during development, but in my experience — no 2.8 yet of course — it produces binaries pretty consistently slower than gcc's and is therefore a worse option for production (and for CI servers and integration of course)

Performance wise I've seen some good results from Clang SVN in the last few months. Not universally faster (or slower) than GCC or ICC, but I have seen (important, useful) cases where code was 30-50% faster compiled with Clang than anything else I tried. (I also saw cases that had terrible performance, and occasionally miscompiled code, though mostly it was +-10% of GCC).

I can't say I understand why anyone would care too much about compilation speed, though - GCC+ccache is about as fast as Clang+ccache, as the primary bottleneck is disk throughput.

> GCC+ccache is about as fast as Clang+ccache, as the primary bottleneck is disk throughput.

I often compile code that has not been compiled before. For example when using MacPorts.

Never underestimate how much people like speed. I never thought SVN was slow or that I needed speed, until I tried git and realized I could not even consider using something slower.

> Never underestimate how much people like speed.

That's one of the main reasons I like Go. It's been explicitly designed to enable fast compilation, and even at this early stage its compilers are very fast.

Even if you're compiling code that you work on all the time changing a compile flag can invalidate all your ccache files. Having to wait 10 seconds instead of 30 for the new compile to finish can make a big difference when you want to be able to test changes quickly.

Well, if your build speed is measured in milliseconds, and then go back to C++ or even C, you'll learn to really appreciate it.

Isn't LLVM is where most of the optimization will be done?

The release notes for 2.8 are here: http://llvm.org/releases/2.8/docs/ReleaseNotes.html

It's in fact LLVM 2.8 that has been released, isn't it?

I have LLVM 2.7 installed and Clang itself says this:

$ clang --version

clang version 1.1

Oops. I installed this release of LLVM and Clang has in fact taken a big jump in version number and is now the same as LLVM, 2.8.