linux下Clang和gcc的区别

·         GCC 在 5.0 之前一直都在准备用 C++ 实现模块化，期待 GCC 的 5.0 会有所突破，补上无法模块化的短板。

 

 

编译速度更快、编译产出更小、出错提示更友好。尤其是在比较极端的情况下。

两年多前曾经写过一个Scheme解释器，词法分析和语法解析部分大约2000行，用的是Boost.Spirit——一个重度依赖C++模版元编程的框架。当时用g++ 4.2编译的情况是：

1. 编译速度极慢：完整编译一次需要20分钟
2. 编译过程中内存消耗极大：单个g++实例内存峰值消耗超过1G
3. 中间产出物极大：编译出的所有.o文件加在一起大约1~2G，debug链接产物超过200M
4. 编译错误极其难以理解：编译错误经常长达几十K，基本不可读，最要命的是编译错误经常会长到被g++截断，看不到真正出错的位置，基本上只能靠裸看代码来调试

这里先不论我使用Spirit的方式是不是有问题，或者Spirit框架自身的问题。我当时因为实在忍受不了g++，转而尝试clang。当时用的是clang 2.8，刚刚可以完整编译Boost，效果让我很满意：

1. 编译速度有显著提升，记得大约是g++的1/3或1/4
2. 编译过程中的内存消耗差别好像不大
3. 中间产出物及最终链接产物，记得也是g++的1/3或1/4
4. 相较于g++，编译错误可读性有所飞跃，至少不会出现编译错误过长被截断的问题了

当时最大的缺点是clang编译出的可执行文件无法用gdb调试，需要用调试器的时候还得用g++再编译一遍。不过这个问题后来解决了，我不知道是clang支持了gdb还是gdb支持了clang。至少我当前在Ubuntu下用clang 3.0编译出的二进制文件已经可以顺利用gdb调试了。

最后一点，其他同学也有讲到，就是Clang采用的是BSD协议。这是苹果资助LLVM、FreeBSD淘汰GCC换用Clang的一个重要原因。

 

 

Clang vs GCC (GNU Compiler Collection)

Pro‘s of GCC vs clang:

• GCC supports languages that clang does not aim to, such as Java, Ada, FORTRAN, Go, etc.
• GCC supports more targets than LLVM.
• GCC supports many language extensions, some of which are not implemented by Clang. For instance, in C mode, GCC supports nested functions and has an extension allowing VLAs in structs.

Pro‘s of clang vs GCC:

• The Clang ASTs and design are intended to be easily understandable by anyone who is familiar with the languages involved and who has a basic understanding of how a compiler works. GCC has a very old codebase which presents a steep learning curve to new developers.
• Clang is designed as an API from its inception, allowing it to be reused by source analysis tools, refactoring, IDEs (etc) as well as for code generation. GCC is built as a monolithic static compiler, which makes it extremely difficult to use as an API and integrate into other tools. Further, its historic design and current policy makes it difficult to decouple the front-end from the rest of the compiler.
• Various GCC design decisions make it very difficult to reuse: its build system is difficult to modify, you can‘t link multiple targets into one binary, you can‘t link multiple front-ends into one binary, it uses a custom garbage collector, uses global variables extensively, is not reentrant or multi-threadable, etc. Clang has none of these problems.
• Clang does not implicitly simplify code as it parses it like GCC does. Doing so causes many problems for source analysis tools: as one simple example, if you write "x-x" in your source code, the GCC AST will contain "0", with no mention of ‘x‘. This is extremely bad for a refactoring tool that wants to rename ‘x‘.
• Clang can serialize its AST out to disk and read it back into another program, which is useful for whole program analysis. GCC does not have this. GCC‘s PCH mechanism (which is just a dump of the compiler memory image) is related, but is architecturally only able to read the dump back into the exact same executable as the one that produced it (it is not a structured format).
• Clang is much faster and uses far less memory than GCC.
• Clang has been designed from the start to provide extremely clear and concise diagnostics (error and warning messages), and includes support for expressive diagnostics. Modern versions of GCC have made significant advances in this area, incorporating various Clang features such as preserving typedefs in diagnostics and showing macro expansions, but GCC is still catching up.
• GCC is licensed under the GPL license. clang uses a BSD license, which allows it to be embedded in software that is not GPL-licensed.
• Clang inherits a number of features from its use of LLVM as a backend, including support for a bytecode representation for intermediate code, pluggable optimizers, link-time optimization support, Just-In-Time compilation, ability to link in multiple code generators, etc.
• Clang‘s support for C++ is more compliant than GCC‘s in many ways.
• Clang supports many language extensions, some of which are not implemented by GCC. For instance, Clang provides attributes for checking thread safety and extended vector types.