Status of NetBSD and LLVM
I've started on getting support for LLVM and Clang as system compiler in NetBSD in 2010. The reach-over frame work was committed last February. Unlike GCC and PCC, I haven't imported the source code yet. It would add a lot of space in the repository and working copies as well as increase the overhead of keeping the copy in NetBSD synchronized with upstream trunk. As such interested parties have to run the "checkout" target in src/external/bsd/llvm to get a fresh copy from svn as well as re-run the target whenever the in-tree version changes. After that, all that is needed is setting MKLLVM=yes and HAVE_LLVM=yes to build the system with Clang.
In my own ATF runs I currently have 8 failures for the Clang world. 5 of the 8 failures are also seen in the ATF runs of the GCC world in the same Virtualbox environment. The remaining cases are as follows:
- lib/libc/ssp/t_ssp's raw test: difference in the stack-protector handling of GCC and Clang. Details in the LLVM bug.
- lib/libpthread/t_cond's cond_timedwait_race test doesn't trigger with Clang. Not analyzed in detail yet.
- lib/semaphore/pthread/t_sem_pth's destroy test fails differently. Not analyzed in detail yet.
For i386, there is one problem in libm, where expf(3) seems to give wrong results, at least that is the reason why the sinhf regression test fails. I haven't looked at this further.
I haven't run any benchmarks yet, so no numbers on code size, execution speed or even build time. The LLVM build is a debug build, so it is slower than necessary.
I'm also running irregular pkgsrc builds with Clang. There are a number of common issues:
- Clang defaults to C99 and is more picky due to that. It implements the C99 inline semantics, which differ from the traditional GCC behavior.
- Clang is a lot stricter as C++ compiler, so a bunch of broken things won't pass, which work silently by GCC due to pruning of dead code.
- CMSG_SPACE and friends are sometimes used as part of a union. NetBSD uses a tricky function internally, so this is not an Integer Constant Expression. Clang rejects using a Variable Length Array as part of a union, while GCC happily accepts that. This is about to be fixed for NetBSD/current.
- Clang doesn't support nested functions. They should be avoided in general, since they require an executable stack. GCC by default doesn't even warn about them.
Help in cutting down the number of trivial build failures would definitely be appreciated. At the moment, almost 1000 packages fail for various reasons, many of them can be fixed in a bunch of minutes.
Update: The correct option is HAVE_LLVM and not HAVE_CLANG.