C is far from dead, it may have its warts but it is still very much in use in all kinds of places and a solid knowledge of C has never hurt anybody (as far as I know).
Being able to compile the linux kernel and to get it to boot is a non-trivial exercise in GCC compatibility, I'm very impressed with this.
I wonder if there ever will be an official 'blessing' by the kernel devs of the LLVM C compiler.
Slightly off-topic, does anyone know if the Gold linker works with Clang?
ICC has been able to compile Linux for awhile, I think.
Also, on some esoteric platforms, GCC dropped compatibility. For example, OpenBSD still supports an older version of GCC for VAX and m88k platforms IIRC.
While being able to compile Linux is definitely helpful and a good sign of compiler maturity, the kernel developers target GCC and I'm not sure that will ever change. This (and similar projects) will probably somewhat limit Clang adoption as people will always need to keep GCC around rather than relying on the portability of using standards. :(
Hopefully the competition Clang brings to the table will push at least some open source projects to be a little less reliant on GNU.
Besides, pluralism is always good, right?
What FS projects do compete for is the time and interest of talented programmers. For that reason, having competing projects can be more harmful to them than good, because it divides the pool of programmers: more programmer time is spent achieving common goals (like having an excellent C compiler) than would be spent if the different groups pooled their efforts.
(This is not, of course, an argument that competing FS projects are always a bad thing. Obviously, competing projects, forks, etc. arise for a variety of reasons, both social and technical. But I am arguing that just competition is not necessarily a good thing, either, especially when competing projects have common goals.)
However, LLVM and JVM dont have much in common. JVM is popular more for its baked in libraries than its instruction set or VM efficiency (though HotSpot is a darned good VM too).
http://clang.llvm.org/diagnostics.html gives some good examples, and my experience has been that the examples given on that page are pretty spot on.
Currently, Clang doesn't support the work-around option that GCC provides to prevent the aforementioned issue. I could just implement the GNU work-around, but with Clang, it's far easier to write a scanner which will identify every place in the Linux source code where those dangerous semantics appear.
Clang might not be mature enough to compile Linux for distribution. The difference between GCC and Clang is that Clang is not a compiler. Clang is a modular API that provides the tools to build C language front-ends to the LLVM compiler infrastructure. The Clang compiler driver is just one implementation of an application built using the Clang libraries.
Why would one want to do this? Well...
// Copyright: (C) 2009 Gilles Muller, Julia Lawall, INRIA, DIKU. GPLv2.
- T i = E->fld;
+ T i;
... when != E
when != i
if (E == NULL) S
+ i = E->fld;
If you have development going on with a different compiler and it's actively maintained to work on both compilers then overall you'd get similar advantages in your code base to those that write cross-platform software. Incidentally, you get the same effect with cross-platform as you're usually targeting different compilers.
Also, with less compiler specific code it will be easier to get the kernel working with other compilers, perhaps ICC.
The difference is that I can pinpoint the error. Clang dies gracefully, with a stack trace, source file location, and, for parse errors, the tokens that are currently being parsed. The problem might not always be easy to fix, but I never have to waste time trying to find it.
If you want a more stable Clang, then build one. ;)
People may help you by suggesting strategies for finding a small test case that tickles the same problem if you post to the mailing list here http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev . I've posted a couple times and found people surprisingly responsive and helpful.
The bug depends on whether or not optimization is on, so it might be in the backend. What I've heard is that the C++ FE in particular still does have some troubles with miscompilations, so that is why I suspect it.
The reasons I get excited:
* speed: faster compilation
* research: interesting code introspection you can't get from GCC.
* proof of concept: if you can build the linux kernel, you can probably build almost any C project
* edit: as mentioned in other comments, competition is good.
The clang static analyzer is now part of my everyday life as a programmer and everytime I read "did you mean..." on the console I am amazed as the first time. It saves me a lot of time (even compile time.)
Clearly, x86 gets the most love. x86, ARM, PPC, and SPARC are listed as "Generally Reliable." Quite an accomplishment, given the difficulty of building up a new compiler from scratch. For now, MIPS is notably missing from the party.
Tinycc is, well, tiny. You can get a working compiler just using syntax-directed translation schemes and it would compile any valid program. The output would even boot, but it would make baby-Muchnick cry.
Any lawyer wants to chime in?
Is there some legal precedent you know of wherein compiler patents extend to the output of the compiler?
By the standard you're setting, the only safe compiler would be one you wrote yourself and revealed to no one. What compilers do you use?