When I went to install the Developer Tools on Snow Leopard yesterday, I noticed that clang 1.0 was included. So, out of curiosity, I decided to mess around with it today.
The first project that I attempted to compile was joe, my most-favorite text editor. The source is straight ANSI C, and highly portable. And to my amazement, I was able to compile joe on my first try, simply using clang as a drop-in replacement for gcc. So now I have a freshly compiled version of joe, that didn't use gcc, and is 64-bit to boot. But I don't have any benchmarks, so I can't tell if I got any sort of performance boost -- but it's pretty unlikely, because text editors don't really stress modern machines that much (well, editors not written in Java anyway).
Emboldened, I decided to try something more complicated, where I might actually see a performance benefit: HandBrake. As it turns out, this was a poor choice. HandBreak actually includes a bunch of other modules (like x264, theora, lame, ffmpeg, etc), some of which include C++ code (which clang can't compile yet), others of which include in-line assembly, and other sorts of gcc-isms. Even worse, it appears as if HandBreak doesn't compile on Snow Leopard at all, even when you try to use gcc.
Chastened, I decided to try something less complex than HandBreak, but where I might actually see a performance benefit: Python. A little over a month ago, I compiled python 2.6.2 on my Mac, for some software that I was working on. Since I had the source already, and knew that it worked (and had something to benchmark against), I decided to give it a whirl. Unfortunately, this too broke when I tried to compile with clang, right on the first file:
intension:~/src/Python-2.6.2$ makeclang -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
In file included from ./Modules/python.c:3:
In file included from Include/Python.h:33:
/usr/include/stdio.h:75:25: error: cannot combine with previous 'type-name' declaration specifier
typedef __darwin_off_t off_t;
^
./pyconfig.h:1057:20: note: instantiated from:
#define off_t long int
^
/usr/include/stdio.h:75:25: error: 'long type-name' is invalid
typedef __darwin_off_t off_t;
^
./pyconfig.h:1057:15: note: instantiated from:
#define off_t long int
^
/usr/include/stdio.h:75:1: error: declaration does not declare anything
typedef __darwin_off_t off_t;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
....
I spent a little time digging around, and I'm not really sure what's going on here. It looks like clang is mad at some of the header files included with Mac OS X. But looking at the referenced python files, and the Mac OS X header files, I didn't see anything amiss. Interestingly, python seems to compile fine with llvm-gcc, so it's probably some sort of gcc-ism that has crept into the python source which is preventing clang from working.
Still, it looks like a lot of progress is being made. My prediction for Mac OS X 10.7: significant chunks of the OS and included applications will ship compiled with clang, and end users will see decent performance improvements.
-Andy.
Update: A little birdie points out that some parts of of Mac OS X 10.6 were compiled with llvm-gcc and clang. So I guess it's not so much as a prediction but more of a "safe bet" that this will expand in Mac OS X 10.7.