所以我在网上逛逛，偶然发现了这篇文章。从根本上说，从版本10及更高版本开始，FreeBSD将弃用GCC，而推荐使用Clang / LLVM。
从到目前为止我在网上看到的内容来看，Clang / LLVM是一个相当雄心勃勃的项目，但是就可靠性而言，它不能与GCC相匹配。
FreeBSD选择LLVM作为其编译器基础结构是否有任何技术原因，还是整个事情归结为永恒的GNU / GPL与BSD许可？
所以我在网上逛逛，偶然发现了这篇文章。从根本上说，从版本10及更高版本开始，FreeBSD将弃用GCC，而推荐使用Clang / LLVM。
从到目前为止我在网上看到的内容来看，Clang / LLVM是一个相当雄心勃勃的项目，但是就可靠性而言，它不能与GCC相匹配。
FreeBSD选择LLVM作为其编译器基础结构是否有任何技术原因，还是整个事情归结为永恒的GNU / GPL与BSD许可？
Answers:
简介： 从GCC切换到Clang的主要原因是GCC的GPL v3许可证与FreeBSD项目的目标不兼容。还存在与公司投资以及用户群需求有关的政治问题。最后，预期的技术优势与标准合规性和调试简便性有关。实际的编译和执行性能改进是特定于代码的，值得商;；两种编译器都可以使用。
FreeBSD和在GPL： FreeBSD的具有与GPL不安的关系。BSD许可证的拥护者认为，真正的免费软件没有使用限制。GPL的倡导者认为，限制是保护软件自由所必需的，特别是从自由软件创建非自由软件的能力是一种不公正的权力形式，而不是自由。FreeBSD项目在可能的情况下尽量避免使用GPL：
由于在GPL软件的商业使用中可能会增加其他复杂性，因此，我们会尽一切可能在FreeBSD许可下尽力用更宽松的FreeBSD许可来替换此类软件。
FreeBSD和在GPL v3的：在GPL v3的明确禁止所谓Tivoisation的代码，在一个漏洞GPL v2协议，这使硬件限制用户以禁止，否则法律修改软件。对于FreeBSD社区中的许多人来说，弥补这一漏洞是不可接受的步骤：
如果当前已获得GPLv2许可的大量软件迁移到新许可证，则设备供应商尤其遭受最大的损失。他们将不再具有使用GPLv3软件的自由并限制对其硬件上安装的软件的修改...总之，大量的OpenSource消费者突然对了解GPL许可软件的替代品非常感兴趣。
由于GCC转向了GPL v3，FreeBSD被迫保留使用GCC 4.2.1（GPL v2），该版本于2007年发布，现在已经大大过时了。即使运行旧的编译器和向后移植修复程序会带来额外的维护麻烦，FreeBSD仍不会使用更现代的GCC版本，这一事实使人们对避免使用GPL v3的需求有一定的了解。C编译器是FreeBSD基础的主要组成部分，“ FreeBSD 10的（暂定）目标之一是不使用GPL的基础系统 ”。
企业投资：与许多大型开源项目一样，FreeBSD也从企业那里获得资金和开发工作。尽管不容易发现FreeBSD由Apple资助或进行开发的程度，但是由于Apple的Darwin OS使用了源于BSD的大量内核代码，因此存在很大的重叠。此外，Clang本身最初是一个内部Apple项目，然后于2007年开源。由于公司资源是FreeBSD项目的关键推动因素，因此满足赞助商的需求可能是推动现实发展的重要因素。
用户群： FreeBSD是许多公司有吸引力的开源选项，因为许可简单，无限制且不太可能引起诉讼。随着GPL v3的到来和新的反Tivoisation条款的出现，已经表明，由供应商驱动的加速趋势是向许可更多的许可。由于FreeBSD对商业实体的明显优势在于其许可许可，因此，企业用户群体面临越来越大的压力，要求他们放弃GCC和GPL。
GCC的问题：除了许可证外，使用GCC还存在一些已知问题。GCC不完全符合标准，并且具有ISO标准C中未发现的许多扩展。它拥有超过300万行代码，也是“ 最复杂和免费/开源软件项目之一 ”。这种复杂性使发行级代码修改成为一项艰巨的任务。
技术优势：与GCC相比， Clang确实具有一些技术优势。最值得注意的是更多有用的错误消息，以及为IDE，重构和源代码分析工具设计的API。尽管Clang网站提供的图表表明编译和内存使用效率更高，但实际结果却变化很大，并且与GCC的性能大致相符。通常，使用Clang生成的二进制文件比等效的GCC二进制文件运行速度更慢：
虽然使用LLVM比GCC更快地构建代码...在大多数情况下，GCC 4.5内置的二进制文件的性能优于LLVM-GCC或Clang ...在其余测试中，性能要么接近于GCC，要么很好背后。在某些测试中，Clang生成的二进制文件的性能简直糟透了。
结论：编译效率极不可能有很大的动力去冒将FreeBSD这样的大型项目迁移到全新的编译器工具链的巨大风险，尤其是在缺乏二进制性能的情况下。但是，这种情况确实不成立。可以选择以下选项之一：1）运行过期的GCC，2）迁移到现代GCC并被迫使用与项目目标不兼容的许可证，或者3）迁移到稳定的BSD许可的编译器，该决定可能是不可避免的。请记住，这仅适用于基本系统，并受发行版的支持；没有什么可以阻止用户自己在FreeBSD盒子上安装和使用现代GCC的。
值得考虑的一件事是，正如ire_and_curses回答中所指出的那样，FreeBSD当前正在使用GCC 4.2.1，因此性能比较与4.5甚至4.6都不与项目真正相关。因此，您应该问的问题是：
该项目使用的新Clang与较旧的GCC有哪些性能提升？
在GCC 4.2.1中编译的相同二进制文件与新Clang相比如何？
由于GCC转向了GPL v3，FreeBSD被迫保留使用GCC 4.2.1（GPL v2），该版本于2007年发布，现在已经大大过时了。
如果Clang落后于当前的GCC，但仍比该项目中已实施的GCC提前数年，那么他们的发展决定是有充分根据的，而且是真正的启发。
即使GCC是GPLv3，由GCC生成的二进制文件也从未受到任何许可证约束。显然，您可以使用GCC来构建属于您想要的许可范围内的软件。即使GCC随附的C库（包含在二进制文件中）也是免许可证的。http://www.gnu.org/licenses/gcc-exception-faq.html
GNU GPLv3第2节：
您有权传播通过将运行时库与独立模块结合而形成的目标代码的工作，即使这种传播否则会违反GPLv3的条款，但前提是所有目标代码均由合格的编译过程生成。然后，您可以根据自己选择的条件传达这些组合，并与独立模块的许可相一致。
“合格”表示该编译不涉及GCC和不兼容GPL的软件。这不是一个限制：可以在涉及GNU GCC的构建过程中使用BSD许可的软件。
如您所见，与上面所说的相反，没有与REAL许可证相关的理由退出GCC，因为在FreeBSD中使用GCC并不存在兼容性。
这种变化背后的真正原因是政治和机会主义：
这些事实为FreeBSD创造了一个摆脱GCC并摆脱它的机会：它们实际上并没有被法律强制，因为他们仍然可以使用GCC来构建免费的或BSD许可的软件，但是他们希望坚持使用。 “所有BSD许可软件”的理念。
license of compiler != license of end product。除非用户不理解该许可证，否则有关编译器许可证的投诉可能不相关。
我不是专家，但我的理解是Clang / LLVM使用的资源少于GCC，而且速度更快。
http://clang.llvm.org/features.html#performance
如果您正在运行一个需要大量构建很多东西的环境，那么这种性能可能会真正节省能源成本和时间。如果是真的。