FreeBSD 10 has had its first alpha release, bringing with it a long planned for change to switch to the Clang compiler instead of GCC on platforms where it is available. (For platforms where Clang has not architecture targets, GCC is still used.) It is also the first FreeBSD release to run on the Raspberry Pi.
The reason for the switch is to do with licensing. GCC used to be available under GPLv2, but in 2009, GCC became licensed under the GPLv3. This wasn't an acceptable license switch for FreeBSD users, who stayed on GCC 4.2.1 as a result. When the more permissively licensed Clang was released, plans were taken to start building FreeBSD with Clang, fixing compiler errors and upstream software packages where necessary. As a result, the FreeBSD 9 system can be built with Clang without any changes required, and in FreeBSD 10 the system itself will be boostrapped and built with Clang.
Clang was switched on as the default compiler for i386 and amd64 platforms almost a year ago, and by earlier this month Clang was used by default for i386, amd64 and powerpc64 platforms. For platforms where GCC is not used, the GCC compiler is no longer built for that platform.
Speed tests (from 2012) showed that Clang was usually faster than the comparative versions of GCC at the time, both in terms of compilation speed and of memory usage. Since these timings were taken, both Clang and GCC have moved forwards in terms of performance and implementation, so the results presented there may not still be relevant.
There's efforts to build Linux with Clang, in the LLVMLinux project, as well as Debian's build of packages with Clang. Of Debian's package base, 11.6% of the packages (2188 out of 18854) fail with an error when building with Clang as compared to when compiled with GCC. Many of these are additional warnings or errors printed by Clang when compiling against code that doesn't warn in GCC, such as non-void function should return a value or where the undefined references point to a specific GCC reference – or in the case of Haskell, a missing library indicated by base_GHCziTopHandler_flushStdHandles_closure which accounts for around 620 of the 770 errors still present in the Clang-compiled Debian packages list. At this year's Linux Plumbers Conference, there is a specific llvm microconference which will be presenting the LLVMLinux talk.
Clang will also shortly gain the ability to generate 64-bit ARM microcode, with Apple's new release of the iPhone 5S (which has a 64-bit CPU). Apple have been heavily investing in the LLVM and Clang platforms, which will be part of LLVM in the future.
With all the changes to compilers happening in the near future, the question of whether compilers are changing too fast or being unsupported has been raised. Miod Vallat asked whether compiler reliability is changing, with a lot of follow-up thoughts on hacker news. Partly the increase in codebases has been due to new standards, but also increases in optimisation routines have added to the size of the compilers. John Rehgr has posted some analysis:
Let’s get back to the original question: Has the reliability of open source compilers decreased since GCC 2.7? This does not appear to be the case. In fact, this experiment indicates that the opposite might be true. Of course we need to be careful in interpreting these results, since randomly generated C programs are not necessarily representative: they could trigger bugs that no real C program triggers, while also missing all of the bugs that Miod is complaining about. Furthermore, GCC 2.7 was never tested with Csmith, but the current versions of GCC and Clang have been subjected to extensive random testing.
The introduction of new automated test tools and suites has certainly improved the quality of compilers over the previous years, and competition between Clang and GCC has increased the amount of work focussed on either platform.