在XCode中冬念，我們經常會看到這些編譯選項（如下圖），有些人可能會有些茫然牧挣，本文將對GCC4.2急前、LLVM GCC 4.2、LLVM compliler 2.0三個編譯選項進行一個詳細的介紹瀑构。
GCC
GCC（GNU Compiler Collection裆针，GNU編譯器套裝），是一套由 GNU 開發(fā)的編程語言編譯器寺晌。它是一套以GPL及LGPL許可證所發(fā)行的自由軟件世吨，也是 GNU計劃的關鍵部分，亦是自由的類Unix及蘋果電腦 Mac OS X操作系統(tǒng)的標準編譯器呻征。
GCC 原名為 GNU C 語言編譯器耘婚，因為它原本只能處理 C語言。GCC 很快地擴展陆赋，變得可處理 C++沐祷。之后也變得可處理 Fortran嚷闭、Pascal、Objective-C赖临、Java, 以及 Ada與其他語言胞锰。
LLVM
LLVM是 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的帳——不給實現(xiàn)，因此索性后來兩者分成兩條分支分別開發(fā)千扶，這也造成Apple的編譯器版本遠落后于GCC的官方版本料祠。另一方面，GCC的代碼耦合度太高澎羞，不好獨立髓绽，而且越是后期的版本，代碼質量越差妆绞，但Apple想做的很多功能（比如更好的IDE支持）需要模塊化的方式來調用GCC顺呕，但GCC一直不給做。甚至最近括饶，《GCC運行環(huán)境豁免條款 （英文版）》從根本上限制了LLVM-GCC的開發(fā)株茶。 所以，這種不和讓Apple一直在尋找一個高效的巷帝、模塊化的忌卤、協(xié)議更放松的開源替代品，于是Apple請來了編譯器高材生Chris Lattner（2000年楞泼，本科畢業(yè)的Chris Lattner像中國多數(shù)大學生一樣驰徊，按部就班地考了GRE笤闯，最終前往UIUC（伊利諾伊大學厄巴納香檳分校），開始了艱苦讀計算機碩士和博士的生涯棍厂。在這階段颗味，他不僅周游美國各大景點，更是努力學習科學文化知識牺弹，翻爛了“龍書”（《Compilers: Principles, Techniques, and Tools》）浦马，成了GPA牛人【注：最終學分積4.0滿分】，以及不斷地研究探索關于編譯器的未知領域张漂，發(fā)表了一篇又一篇的論文晶默，是中國傳統(tǒng)觀念里的“三好學生”。他的碩士畢業(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實現(xiàn)被用在了后來發(fā)布的Mac OS X 10.5上雏逾。同時嘉裤，LLVM的鏈接優(yōu)化被直接加入到Apple的代碼鏈接器上，而LLVM-GCC也被同步到使用GCC4代碼栖博。
Clang歷史
Apple吸收Chris Lattner的目的要比改進GCC代碼優(yōu)化宏大得多——GCC系統(tǒng)龐大而笨重屑宠，而Apple大量使用的Objective-C在GCC中優(yōu)先級很低。此外GCC作為一個純粹的編譯系統(tǒng)仇让，與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運行庫的函數(shù)調用虚吟，因此在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，參見http://clang.llvm.org/cxx_status.html抖格。（近日 Clang 已經可以自編譯诺苹，見http://www.phoronix.com/scan.php?page=news_item&px=Nzk2Mw）
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ā)現(xiàn)任何問題。
參考文檔：
http://baike.baidu.com/view/4848.htm
http://hi.baidu.com/zhanghuikl/blog/item/71e8a6018172df0f728da53e.html
