Why is FreeBSD deprecating GCC in favor of Clang/LLVM?
Summary: The primary reason for switching from GCC to Clang is the incompatibility of GCC's GPL v3 license with the goals of the FreeBSD project. There are also political issues to do with corporate investment, as well as user base requirements. Finally, there are expected technical advantages to do with standards compliance and ease of debugging. Real world performance improvements in compilation and execution are code-specific and debatable; cases can be made for both compilers.
FreeBSD and the GPL: FreeBSD has an uneasy relationship with the GPL. BSD-license advocates believe that truly free software has no usage restrictions. GPL advocates believe that restrictions are necessary in order to protect software freedom, and specifically that the ability to create non-free software from free software is an unjust form of power rather than a freedom. The FreeBSD project, where possible, tries to avoid the use of the GPL:
Due to the additional complexities that can evolve in the commercial use of GPL software, we do, however, endeavor to replace such software with submissions under the more relaxed FreeBSD license whenever possible.
FreeBSD and the GPL v3: The GPL v3 explicitly forbids the so-called Tivoisation of code, a loophole in the GPL v2 which enabled hardware restrictions to disallow otherwise legal software modifications by users. Closing this loophole was an unacceptable step for many in the FreeBSD community:
Appliance vendors in particular have the most to lose if the large body of software currently licensed under GPLv2 today migrates to the new license. They will no longer have the freedom to use GPLv3 software and restrict modification of the software installed on their hardware... In short, there is a large base of OpenSource consumers that are suddenly very interested in understanding alternatives to GPL licensed software.
Because of GCC's move to the GPL v3, FreeBSD was forced to remain using GCC 4.2.1 (GPL v2), which was released way back in 2007, and is now significantly outdated. The fact that FreeBSD did not move to use more modern versions of GCC, even with the additional maintenance headaches of running an old compiler and backporting fixes, gives some idea of the strength of the requirement to avoid the GPL v3. The C compiler is a major component of the FreeBSD base, and "one of the (tentative) goals for FreeBSD 10 is a GPL-free base system".
Corporate investment: Like many major open source projects, FreeBSD receives funding and development work from corporations. Although the extent to which FreeBSD is funded or given development by Apple is not easily discoverable, there is considerable overlap because Apple's Darwin OS makes use of substantial BSD-originated kernel code. Additionally, Clang itself was originally an in-house Apple project, before being open-sourced in 2007. Since corporate resources are a key enabler of the FreeBSD project, meeting sponsor needs is probably a significant real-world driver.
Userbase: FreeBSD is an attractive open source option for many companies, because the licensing is simple, unrestrictive and unlikely to lead to lawsuits. With the arrival of GPL v3 and the new anti-Tivoisation provisions, it has been suggested that there is an accelerating, vendor-driven trend towards more permissive licenses. Since FreeBSD's perceived advantage to commercial entities lies in its permissive license, there is increasing pressure from the corporate user base to move away from GCC, and the GPL in general.
Issues with GCC: Apart from the license, using GCC has some perceived issues. GCC is not fully-standards compliant, and has many extensions not found in ISO standard C. At over 3 million lines of code, it is also "one of the most complex and free/open source software projects". This complexity makes distro-level code modification a challenging task.
Technical advantages: Clang does have some technical advantages compared to GCC. Most notable are much more informative error messages and an explicitly designed API for IDEs, refactoring and source code analysis tools. Although the Clang website presents plots indicating much more efficient compilation and memory usage, real world results are quite variable, and broadly in line with GCC performance. In general, Clang-produced binaries run more slowly than the equivalent GCC binaries:
While using LLVM is faster at building code than GCC... in most instances the GCC 4.5 built binaries had performed better than LLVM-GCC or Clang... in the rest of the tests the performance was either close to that of GCC or well behind. In some tests, the performance of the Clang generated binaries was simply awful.
Conclusion: It's highly unlikely that compilation efficiency would be a significant motivator to take the substantial risk of moving a large project like FreeBSD to an entirely new compiler toolchain, particularly when binary performance is lacking. However, the situation was not really tenable. Given a choice between 1) running an out-of-date GCC, 2) Moving to a modern GCC and being forced to use a license incompatible with the goals of the project or 3) moving to a stable BSD-licensed compiler, the decision was probably inevitable. Bear in mind that this only applies to the base system, and support from the distribution; nothing prevents a user from installing and using a modern GCC on their FreeBSD box themselves.
One thing worth considering is that FreeBSD is currently using GCC 4.2.1 as noted in ire_and_curses answer thus the performance comparisons aren't of 4.5 or even 4.6 aren't truly relevant to the project. Therefore, the questions you should be asking are:
What are the performance gains of the new Clang vs the older GCC that the project uses?
How do the same binaries compiled in GCC 4.2.1 compare to the new Clang?
Because of GCC's move to the GPL v3, FreeBSD was forced to remain using GCC 4.2.1 (GPL v2), which was released way back in 2007, and is now significantly outdated.
If Clang lags behind the current GCC but is still light years ahead of the implemented GCC in the project then their decision to evolve is well warranted and truly inspired.
Even though GCC is GPLv3, the resulting binaries produced by GCC never had any license constraint. In clear you can use GCC to build software that falls under the license you want. Even the C library that comes with GCC and that is included in the binary is license-free. http://www.gnu.org/licenses/gcc-exception-faq.html
Section 2 of the GNU GPLv3:
You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules.
“Eligible” means that the compilation does not involve both GCC and GPL-incompatible software. That's not a restriction: BSD-licensed software can be used in the build process involving GNU GCC.
As you can see, contrary to what has been said above, there is no REAL license-related reason to move away from GCC as there is no incompatibility with using GCC inside FreeBSD.
The real reason behind this change is political and opportunistic:
- BSD has its own licensing which philosophically competes with the GNU Public license (as *ire_and_curses* explained above),
- CLANG is a new non-GPL compiler initiated by a sponsor of FreeBSD that appears to be technically equivalent to the GPL-licensed GCC (as described above by *ire_and_curses*).
These facts creates an opportunity for FreeBSD to move away from GCC and get rid of it: they're not actually legally compelled to, as they could well still use GCC to build free or BSD-licensed software, but they want to stick to the "all BSD licensed software" philosophy.