linux下Clang和gcc的區別

Clang 比 GCC 編譯器的優勢：

編譯速度更快

編譯產出更小

出錯提示更友 好，比如 clang 在編譯過程可以直接指出相對簡單的出錯位置以及它 “ 認為 ” 正確的方式 。

內置有靜態分析工具，可以對代碼進行靜態分析 (clang—analyze) 。這也是 gcc 做不到的 。

專注，因為 clang 只需要完成詞法和語法分析，代碼優化和機器代碼的生成工作由 llvm 完成。所以和全部由自己包下的 gcc 比起來， clang 可以更專注地做好一件事。這種結構也使 clang 可以被單獨拿出來用在其他的程序里，成為其它 app （主要是 IDE）的內嵌 C/C++ parser 。 對於 IDE 而言，代碼補全、重構是重要的功能，然而如果沒有底層的支持，只使用 tags 分析或是正則表達式匹配是很難達成的， clang正好充當了這一角色。 這樣， editor 工具可以使用和 compiler 一樣的 parser 來完成 edit-time 的語法檢查 。 而 gcc 就沒法很方便地做到這一點 。由於歷史原因， GCC 是一個單一的可執行程序編譯器，其內部完成了從預處理到最后代碼生成的全部過程，中間諸多信息都無法被其他程序重用。

 Gcc 的優勢：

·         一些軟件用 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.