求科普---关于llvm/clang 和 GCC

1.先有的llvm，始于Chris Lattner的一篇论文
2.llvm被苹果用于辅助显卡工作
3.llvm以库的形式提供编译器后端的功能，同时能提供runtime的支持，包括虚拟机和JIT优化
4.苹果对GPLv3也有些不爽；后来需要做IDE的支持，限于协议不能拿Gcc来改，于是干脆开始了clang项目，同时也使得llvm有了自己的C/C++前端。在此之前则使用的Gcc前端。
5.clang/llvm的模块化做的都很好，clang也提供了接口可以把它当作库来使用。Gcc表示我需要模仿一下。
6.链接时优化，这个clang/llvm实现之后gcc也模仿了一下。
7.性能问题：编译的性能提升不是一朝一夕的事儿，显然llvm还太年轻。至于什么1600倍，显然是特例。
8.说道编译速度这个卖点，已经看到有人说实测clang/llvm不怎么快了。后端优化很耗时间，llvm优化做的多了肯定会慢下来。
9.BSD社区不爽GPLv3很多年，所以他们使用的gcc停留在4.2。现在，终于有了出头之日了。
10.但是，作为事实上的工业标准，gcc对C/C++（主要是C，C++的标准特性实现都是问题...）做了太多变态的扩展，这直接让立志兼容gcc的clang/llvm哭了。对于有的特性，clang直接表示我不支持，并且永远不支持。这导致很多gcc可以过的代码clang过不了。而linux kernel作为gcc的铁杆用户，使用的gcc特性可真不少。有些驱动就用了clang明确不支持的特性（但还偏偏有人对用clang/llvm编kernel非常热心...）。
11.clang的错误提示比gcc好很多，很精确。什么？你说C++的模板编译错？这个别想了。


楼上最后一句亮了…本吧似乎不欢迎++啊

就是一个渣编译器…对C++11竟然 还有两个语法特性不支持…继承构造函数（这是我翻的）＆属性（还是我翻的）

本吧是谁?

8pm微微一笑：我才是本吧。
顺带补充一点：对C++模板导致的代码膨胀问题没有深刻体会的可以用ls看一下clang的可执行文件大小。

我觉得人们可能感兴趣的点：易得的 AST，较少历史负担，较宽松的 license，JIT 的可能

拒绝被堆火坑 ;p

我是指linux吧…

^_^
顺带再补充一点，内存小于等于1G的同学请不要尝试自行编译clang/llvm。

这个还好
$ eix -c 'clang|llvm'
[I] sys-devel/clang (3.0-r3@02/16/2012): C language family frontend for LLVM
[I] sys-devel/llvm (3.0-r2@03/27/2012): Low Level Virtual Machine
Found 2 matches.
倒是 PyPy 在 x86_64 中 translate 需要 4G，刚开始不知道，等半天

自行编译失败的路过…太打击人了…这是我第一个自行编译的程序啊【MacPorts不算】…

额好吧～我去唯物～

大神解释的很清晰了～明白了～