As somebody who is learning C++ and decided to go with clang, the error reporting is absolutely phenomenal. It tells me not only what line errors are on but also makes suggestions as to how to fix it. I don't ever recall GCC having very helpful error messages.
GCC has nested functions, which most GCC users hate. Clang has blocks, which are at least widely used on OS X at least and proposed for standardization. I'm not sure this is a point in GCC's favor.
As an Objective-C (iOS) developer, I really love blocks. I thought the syntax was kind of weird when starting to learn it, but it's grown on me. I really hope ObjC blocks will become part of the C standard someday. If I remember people have proposed C++ lambdas to become part of the C standard as well. It will be interesting to see which one (if any) will win in a standardising process.
Is that C language features or compiler-specific extensions? Arguably, sticking to the standard is actually the better alternative here in terms of portability.
LLVM has a BSD-license. This might be a big deal for some people from a philosophical perspective, but at a more practical level it's great when you need to embed a compiler in your product.
It has nothing to do with "custom C code". Any tool with a custom language (or equivalent) that wants a runtime JIT for the language and code compilable to LLVM IR would need to link in the compiler libs to do that. Custom DSLs are everywhere.
For example, OpenShadingLanguage compiles shaders on the fly as part of a physically-based renderer, and then JITs them at runtime with LLVM. Linked in are the LLVM libs and a bunch of C code that is converted to LLVM IR and accessed by the shaders. The whole lot is linked and JITd together, enabling interprocedural analysis, inlining and a bunch of other compiler optimizations (e.g. constant folding). The resulting shaders are about 25% faster than their previous, hand-coded C shaders.
IOW, lots of products benefit from having a compiler toolchain at runtime they can link with their program. GPL license or not, GCC isn't made to do that.
Suppose you're writing an IDE, and you want to use the clang code to do the heavy lifting of making your editor aware of your program's AST, so that you can easily colorize it, provide in-line warnings & errors, and offer fix-it suggestions.
They use the LGPL license. The idea is that you can make closed source programs that link to the Racket system as a library, but you must provide a version that is linkable to newer versions of Racket. But in Racket the macro expansions are a fundamental part so the more strict interpretation means almost that you must provide the original source code in plain text.
I don't know enough about licenses, perhaps this is only FUD. And my impression is that the intensions of the Racket creators is that closed source programs in Racket are allowed, but this looks like a gray area.
And the GPL license is more restrictive, but C/C++ has many less macros/templates than Racket.
Cloudera Impala uses LLVM to generate code optimized for the specific query it is running (basically compiling away all the generalness around how large records are, etc). Some kind of native code generation is apparently standard practice in high-performance query engines that are written in languages that don't have a JIT.
Why would it have to be "C code"? LLVM can compile any kind of code with the appropriate front-end. For example, Apple uses it in their OpenGL pipeline, in the (previously Apple sponsored) MacRuby, etc.
Because both LLVM and Clang are librarified from the off, so you can hook them into your own code and use as much or as little of them as you want. You can insert your own passes, make your own drivers, add your own analyses to the static analyzer (http://llvm.org/devmtg/2012-11/Zaks-Rose-Checker24Hours.pdf). Or use it to get information to show in an IDE.
