在XCode中，我們經常會看到這些編譯選項（如下圖），有些人可能會有些茫然袜漩，本文將對GCC4.2绪爸、LLVM GCC 4.2、LLVM compliler 2.0三個編譯選項進行一個詳細的介紹宙攻。
GCCGCC（GNU Compiler Collection奠货，GNU編譯器套裝），是一套由 GNU 開發(fā)的編程語言編譯器座掘。它是一套以 GPL 及 LGPL 許可證所發(fā)行的自由軟件递惋，也是 GNU計劃的關鍵部分，亦是自由的類Unix及蘋果電腦 Mac OS X 操作系統的標準編譯器溢陪。GCC 原名為 GNU C 語言編譯器萍虽，因為它原本只能處理 C語言。GCC 很快地擴展形真，變得可處理 C++杉编。之后也變得可處理 Fortran、Pascal咆霜、Objective-C邓馒、Java, 以及 Ada與其他語言。LLVMLLVM 是 Low Level Virtual Machine 的簡稱蛾坯，這個庫提供了與編譯器相關的支持光酣，能夠進行程序語言的編譯期優(yōu)化、鏈接優(yōu)化脉课、在線編譯優(yōu)化救军、代碼生成。簡而言之倘零，可以作為多種語言編譯器的后臺來使用缤言。如果這樣還比較抽象的話，介紹下 Clang 就知道了：Clang 是一個 C++ 編寫视事、基于 LLVM胆萧、發(fā)布于 LLVM BSD 許可證下的 C/C++/Objective C/Objective C++ 編譯器，其目標（之一）就是超越 GCC俐东。LLVM歷史Apple（包括中后期的NeXT） 一直使用GCC作為官方的編譯器跌穗。GCC作為開源世界的編譯器標準一直做得不錯，但Apple對編譯工具會提出更高的要求虏辫。一方面蚌吸，是Apple對Objective-C語言（甚至后來對C語言）新增很多特性，但GCC開發(fā)者并不買Apple的帳——不給實現砌庄，因此索性后來兩者分成兩條分支分別開發(fā)羹唠，這也造成Apple的編譯器版本遠落后于GCC的官方版本奕枢。另一方面，GCC的代碼耦合度太高佩微，不好獨立缝彬，而且越是后期的版本，代碼質量越差哺眯，但Apple想做的很多功能（比如更好的IDE支持）需要模塊化的方式來調用GCC谷浅，但GCC一直不給做。甚至最近奶卓，《GCC運行環(huán)境豁免條款 （英文版）》從根本上限制了LLVM-GCC的開發(fā)一疯。 所以，這種不和讓Apple一直在尋找一個高效的夺姑、模塊化的墩邀、協議更放松的開源替代品，于是Apple請來了編譯器高材生Chris Lattner（2000年盏浙，本科畢業(yè)的Chris Lattner像中國多數大學生一樣眉睹，按部就班地考了GRE，最終前往UIUC（伊利諾伊大學厄巴納香檳分校）只盹，開始了艱苦讀計算機碩士和博士的生涯辣往。在這階段兔院，他不僅周游美國各大景點殖卑，更是努力學習科學文化知識，翻爛了“龍書”（《Compilers: Principles, Techniques, and Tools》）坊萝，成了GPA牛人【注：最終學分積4.0滿分】孵稽，以及不斷地研究探索關于編譯器的未知領域，發(fā)表了一篇又一篇的論文十偶，是中國傳統觀念里的“三好學生”菩鲜。他的碩士畢業(yè)論文提出了一套完整的在編譯時、鏈接時惦积、運行時甚至是在閑置時優(yōu)化程序的編譯思想接校，直接奠定了LLVM的基礎。LLVM在他念博士時更加成熟狮崩，使用GCC作為前端來對用戶程序進行語義分析產生IF（Intermidiate Format）蛛勉，然后LLVM使用分析結果完成代碼優(yōu)化和生成。這項研究讓他在2005年畢業(yè)時睦柴，成為小有名氣的編譯器專家诽凌，他也因此早早地被Apple相中，成為其編譯器項目的骨干）坦敌。剛進入Apple侣诵，Chris Lattner就大展身手：首先在OpenGL小組做代碼優(yōu)化痢法，把LLVM運行時的編譯架在OpenGL棧上，這樣OpenGL棧能夠產出更高效率的圖形代碼杜顺。如果顯卡足夠高級财搁，這些代碼會直接扔入GPU執(zhí)行。但對于一些不支持全部OpenGL特性的顯卡（比如當時的Intel GMA卡）哑舒，LLVM則能夠把這些指令優(yōu)化成高效的CPU指令妇拯，使程序依然能夠正常運行。這個強大的OpenGL實現被用在了后來發(fā)布的Mac OS X 10.5上洗鸵。同時越锈，LLVM的鏈接優(yōu)化被直接加入到Apple的代碼鏈接器上，而LLVM-GCC也被同步到使用GCC4代碼膘滨。Clang歷史Apple吸收Chris Lattner的目的要比改進GCC代碼優(yōu)化宏大得多——GCC系統龐大而笨重甘凭，而Apple大量使用的Objective-C在GCC中優(yōu)先級很低。此外GCC作為一個純粹的編譯系統火邓，與IDE配合得很差丹弱。加之許可證方面的要求，Apple無法使用LLVM 繼續(xù)改進GCC的代碼質量铲咨。于是躲胳，Apple決定從零開始寫 C、C++纤勒、Objective-C語言的前端 Clang坯苹，完全替代掉GCC。正像名字所寫的那樣摇天，Clang只支持C粹湃，C++和Objective-C三種C家族語言。2007年開始開發(fā)泉坐，C編譯器最早完成为鳄，而由于Objective-C相對簡單，只是C語言的一個簡單擴展腕让，很多情況下甚至可以等價地改寫為C語言對Objective-C運行庫的函數調用孤钦，因此在2009年時，已經完全可以用于生產環(huán)境纯丸。C++的支持也熱火朝天地進行著偏形。下面這張圖將顯示GCC、LLVM-GCC液南、LLVM Compiler這三個編譯選項的不同點：
對比作為一種新的編譯器壳猜，我們來看Clang和GCC各有什么優(yōu)缺點：Clang特性快：通過編譯 OS X 上幾乎包含了所有 C 頭文件的 carbon.h 的測試，包括預處理 (Preprocess)滑凉，語法 (lex)统扳，解析 (parse)喘帚，語義分析 (Semantic Analysis)，抽象語法樹生成 (Abstract Syntax Tree) 的時間咒钟，Clang 是 Apple GCC 4.0 的 2.5x 快吹由。(2007-7-25)內存占用小：Clang 內存占用是源碼的 130%朱嘴，Apple GCC 則超過 10x倾鲫。診斷信息可讀性強：我不會排版，推薦去網站觀看萍嬉。其中錯誤的語法不但有源碼提示乌昔，還會在錯誤的調用和相關上下文的下方有~~~~~和^的提示，相比之下 GCC 的提示很天書壤追。GCC 兼容性磕道。設計清晰簡單，容易理解行冰，易于擴展增強溺蕉。與代碼基礎古老的 GCC 相比，學習曲線平緩悼做》杼兀基于庫的模塊化設計，易于 IDE 集成及其他用途的重用肛走。由于歷史原因漓雅，GCC 是一個單一的可執(zhí)行程序編譯器，其內部完成了從預處理到最后代碼生成的全部過程羹与，中間諸多信息都無法被其他程序重用故硅。Clang 將編譯過程分成彼此分離的幾個階段庶灿，AST 信息可序列化纵搁。通過庫的支持，程序能夠獲取到 AST 級別的信息往踢，將大大增強對于代碼的操控能力腾誉。對于 IDE 而言，代碼補全峻呕、重構是重要的功能利职，然而如果沒有底層的支持，只使用 tags 分析或是正則表達式匹配是很難達成的瘦癌。當然猪贪，GCC 也有其優(yōu)勢：支持 JAVA/ADA/FORTRAN當前的 Clang 的 C++ 支持落后于 GCC，參見Clang - C++1z, C++14, C++11 and C++98 Status**讯私。（近日 Clang 已經可以自編譯热押，見LLVM's Clang Now Can Build Itself**）GCC 支持更多平臺GCC 更流行西傀，廣泛使用，支持完備GCC 基于 C桶癣，不需要 C++ 編譯器即可編譯要選擇哪個那么三個編譯選項拥褂，要選擇哪一個呢？目前不推薦使用老的GCC4.2牙寞，因為蘋果不會維持它了饺鹃，而且LLVM-GCC看起來會更好。在項目中途改編譯選項可是一個大變動间雀，所以悔详，如果你要改，當然需要經過慎重完整的測試惹挟。對新的項目而言伟端，LLVM-GCC看起來應該是個安全的選擇，蘋果公司認為它夠穩(wěn)定夠成熟匪煌，所以才把它當做Xcode 4的預設選項（你或許不會把穩(wěn)定成熟這兩個字眼跟Xcode 4本身畫上等號）责蝠，而且，既然選項使用的是GCC parser萎庭，向后兼容性應該沒問題霜医。我說LLVM-GCC是個安全的選項，但我并不是指Clang/LLVM比較不安全驳规，只是成熟度還沒那么高效了肴敛，我將一些以前的代碼拿到Xcode 4上，使用LLVM 2.0編譯器重新編譯吗购，到目前為止還沒發(fā)現任何問題医男。