llvm編譯器與gcc

① 安裝xcode 6後，為什麼在MAC電腦的terminal里打gcc -v 會顯示LLVMLLVM和GCC不是兩個不同的編譯器嗎

Mac OS 現在都是默認使用clang+llvm編譯，以前使用gcc+llvm。
只是現在還可以使用gcc命令 [編譯實際還是用clang+llvm編譯]。
要想用gcc, 需要自己單獨裝。

② 單純的只寫c++，學生用的，哪個軟體比較好

Visual Studio，這是最好的，沒有之一。我干C++程序員10多年了，用了很多IDE，包括Eclipse、Tubo C++、C++ Builder等等，最後還是發現Visual Studio最好用，響應速度最快，功能最全。寫C++的話推薦Visual Studio 2017，這個版本對C++11的支持比較全面，同時又比Visual Studio 2019穩定，基本沒有Bug，學生的話安裝Visual Studio 2017 Community版本，免費的。寫C++一定要安裝VAX插件，能提高編寫代碼的速度50%以上，VAX雖然是收費的，但這是中國，免費(pojie)版了解一下？

③ Clang 比 GCC 好在哪裡

從代碼上說，clang結構更簡單。因為clang只需要完成詞法和語法分析，代碼優化和機器代碼的生成工作由llvm完成。所以和全部由自己包下的gcc比起來，clang可以更專注地做好一件事。

這種結構也使clang可以被單獨拿出來用在其他的程序里。比如vim的clang_complete插件就是利用clang進行語法分析後給出精確的自動補全和語法錯誤提示的。而gcc就沒法很方便地做到這一點。

在實用性方面，除了有更快的編譯速度更快和更友好的出錯提示外，clang還內置有靜態分析工具，可以對代碼進行靜態分析（clang --analyze）。這也是gcc做不到的。

總結如下：

Clang是LLVM的前端，可以用來編譯C，C++，ObjectiveC等語言。傳統的編譯器通常分為三個部分，前端(frontEnd)，優化器(Optimizer)和後端(backEnd)。

在編譯過程中，前端主要負責詞法和語法分析，將源代碼轉化為抽象語法樹；優化器則是在前端的基礎上，對得到的中間代碼進行優化，使代碼更加高效；後端則是將已經優化的中間代碼轉化為針對各自平台的機器代碼。Clang則是以LLVM為後端的一款高效易用，並且與IDE結合很好的編譯前端。

④ LLVM相比於GCC，有哪些技術上的優勢

首先簡要介紹一下LLVM。LLVM是一個針對LLVM Intermediate Representation（IR，中間語言）的跨平台優化編譯器，它的模塊化設計很好，使得這個編譯器中的很多功能可以被單獨實現或者改進，這與其C++實現無法分開。由此，LLVM可以被設計成很多語言編譯器實現的後端，負責處理程序優化和跨平台，而前端只需將程序轉換成LLVM IR即可。比如說，Clang就是基於LLVM實現的C/C++編譯器，它的主要功能就是將C/C++程序轉換成LLVM IR，然後由LLVM負責後續的工作。

LLVM技術上的（最大）優勢就在於它的模塊化設計。在LLVM中，IR的解析，優化，匯編碼的生成，寄存器分配，匯編碼優化以及機器碼生成，各種類型的二進制文件生成全部都是介面定義清晰的模塊完成的，很容易分別改進或者添加定製功能。而且由於LLVM的C++實現，很多模塊理解和使用比較容易。這些特性使得LLVM可以很容易地被用在科研和生產實踐當中。反觀GCC，模塊化做得不如LLVM好，這使得它定製或者改進比較不方便。

⑤ 比較gcc，llvm和商用編 譯器的性能差異，說明是什麼原因導致差異 的出現

Apple在LLVM GCC4.2編譯器中，通過XCode中的提示介面顯式地為程序員提供是否將目標代碼編譯為ARM的選項。而在Apple LLVM3.0中，此選項沒有了。
由於採用ARMv7A架構的Apple A4/A5處理器擁有Thumb-2指令集，使得Thumb代碼在確保緊湊性的同時又進一步提升了計算能力。因此，Apple將工程配置默認設置為編譯為Thumb代碼。
而又由於LLVM的編譯選項基本與GCC兼容，因此我們只需要在編譯選項中手動加入-marm即可。
而傳統GCC的編譯選項只有-mthumb，它默認將代碼編譯為ARM指令集，因此可能沒有提供-marm的編譯選項。不過-marm在Apple LLVM3.0中確實奏效了。

⑥ armcc vs gcc,及llvm目前的使用情況是什麼樣的

armcc 在代碼的體積上相比與開源gcc編譯器更好，而且作為商業產品，能涉及到處理器的更多細節，所做出來的優化應該也更好，想比較而言，gcc就更加的保守了。llvm最近勢頭很猛，因為使用不同的licence，一些商業公司比較青睞，而且作為後發起的項目，在初始設計的時候就考慮到gcc現存的一些問題，更加模塊化，有很多先天的優勢吧。但是gcc也在一步步進化，畢竟在目前的開源界，它還是標配吧。

⑦ 適合win10系統的c語言編譯器

桌面操作系統

對於當前主流桌面操作系統而言，可使用 VisualC++、GCC以及 LLVM Clang 這三大編譯器。

Visual C++（簡稱 MSVC）只能用於 Windows 操作系統；GCC 和 LLVM Clang除了可用於Windows操作系統之外，主要用於 Unix/Linux操作系統。

像現在很多版本的 Linux 都默認使用 GCC 作為C語言編譯器，而像 FreeBSD、macOS 等系統默認使用 LLVM Clang 編譯器。由於當前 LLVM 項目主要在 Apple 的主推下發展的，所以在 macOS中，Clang 編譯器又被稱為 Apple LLVM 編譯器。

MSVC 編譯器主要用於 Windows 操作系統平台下的應用程序開發，它不開源。用戶可以使用 Visual Studio Community 版本來免費使用它，但是如果要把通過 Visual Studio Community 工具生成出來的應用進行商用，那麼就得好好閱讀一下微軟的許可證和說明書了。

而使用 GCC 與 Clang 編譯器構建出來的應用一般沒有任何限制，程序員可以將應用程序隨意發布和進行商用。

MSVC 編譯器對 C99 標準的支持就十分有限，加之它壓根不支持任何 C11 標准，所以本教程中設計 C11 的代碼例子不會針對 MSVC 進行描述。所幸的是，Visual Studio Community 2017 加入了對 Clang 編譯器的支持，官方稱之為——Clang with Microsoft CodeGen，當前版本基於的是 Clang 3.8。

也就是說，應用於 Visual Studio 集成開發環境中的 Clang 編譯器前端可支持 Clang 編譯器的所有語法特性，而後端生成的代碼則與 MSVC 效果一樣，包括像 long 整數類型在 64 位編譯模式下長度仍然為 4 個位元組，所以各位使用的時候也需要注意。

為了方便描述，本教程後面涉及 Visual Studio 集成開發環境下的 Clang 編譯器簡稱為 VS-Clang 編譯器。

嵌入式系統

而在嵌入式系統方面，可用的C語言編譯器就非常豐富了，比如：

• 用於 Keil 公司 51 系列單片機的 Keil C51 編譯器；

• 當前大紅大紫的 Arino 板搭載的開發套件，可用針對 AVR 微控制器的 AVRGCC 編譯器；

• ARM 自己出的 ADS（ARM Development Suite）、RVDS（RealView Development Suite）和當前最新的 DS-5 Studio；

• DSP 設計商 TI（Texas Instruments）的 CCS（Code Composer Studio）；

• DSP 設計商 ADI（Analog Devices，Inc.）的 Visual DSP++ 編譯器，等等。



• 通常，用於嵌入式系統開發的編譯工具鏈都沒有免費版本，而且一般需要通過國內代理進行購買。所以，這對於個人開發者或者嵌入式系統愛好者而言是一道不低的門檻。



• 不過 Arino 的開發套件是可免費下載使用的，並且用它做開發板連接調試也十分簡單。Arino 所採用的C編譯器是基於 GCC 的。



• 還有像樹莓派（Raspberry Pi）這種迷你電腦可以直接使用 GCC 和 Clang 編譯器。此外，還有像 nVidia 公司推出的 Jetson TK 系列開發板也可直接使用 GCC 和 Clang 編譯器。樹莓派與 Jetson TK 都默認安裝了 Linux 操作系統。



• 在嵌入式領域，一般比較低端的單片機，比如 8 位的 MCU 所對應的C編譯器可能只支持 C90 標准，有些甚至連 C90 標準的很多特性都不支持。因為它們一方面內存小，ROM 的容量也小；另一方面，本身處理器機能就十分有限，有些甚至無法支持函數指針，因為處理器本身不包含通過寄存器做間接過程調用的指令。



• 而像 32 位處理器或 DSP，一般都至少能支持 C99 標准，它們本身的性能也十分強大。而像 ARM 出的 RVDS 編譯器甚至可用 GNU 語法擴展。



• 下圖展示了上述C語言編譯器的分類。

⑧ LLVM/GCC中如何使用Intel格式的匯編

盡管本人接觸GCC已經很久了，但對於AT&T匯編還是不忒習慣，尤其是寫SSE的時候很別扭，呵呵。因此如果能寫Intel格式匯編的話就會非常舒服。下面提供此方法（註：此方法已經在Apple LLVM1.6編譯器下成功通過）
int main(int argc, const char * argv[]){__asm__ volatile(".intel_syntax /n/t" "mov r8, qword ptr [r8] /n/t" "mov r9, r9");
__asm__ volatile(".att_syntax /n/t" "mov %r8, %r8 /n/t" "mov %r9, %r9");}
上述代碼中，第一行使用了Intel格式的內聯匯編；第二行則是AT&T的。
上述代碼對應的反匯編將是：Ltmp5:## InlineAsm Start
.intel_syntax
mov r8, qword ptr [r8]mov r9, r9## InlineAsm EndLtmp6:## InlineAsm Start
.att_syntax
mov %r8, %r8
mov %r9, %r9
## InlineAsm End
這里要注意的是，當你用完Intel內聯匯編後，務必再切換回AT&T格式，否則編譯器可能會發生故障，呵呵�6�8�6�8比如：int main(int argc, const char * argv[]){NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
__asm__ volatile(".intel_syntax /n/t" "mov r8, qword ptr [r8] /n/t" "mov r9, r9 /n/t"
".att_syntax /n/t");
[pool drain];return 0;}
如果上述代碼中，最後沒有切換AT&T語法格式，那麼編譯器會有莫名其妙的錯誤。上述代碼內聯匯編部分所對應的反匯編是：
## InlineAsm Start
.intel_syntax
mov r8, qword ptr [r8]mov r9, r9
這里要注意的是，從LLVM2.0開始，其自帶的匯編器就不再支持Intel匯編語法了。

⑨ LLVM和GCC的區別

LLVM與GCC在三段式架構上並沒有本質區別。LLVM與其它編譯器最大的差別是，它不僅僅是Compiler
Collection，也是Libraries
Collection。舉個例子，假如說我要寫一個XYZ語言的優化器，我自己實現了PassXYZ演算法，用以處理XYZ語言與其它語言差別最大的地方。而LLVM優化器提供的PassA和PassB演算法則提供了XYZ語言與其它語言共性的優化演算法。那麼我可以選擇XYZ優化器在鏈接的時候把LLVM提供的演算法鏈接進來。LLVM不僅僅是編譯器，也是一個SDK。

⑩ 編譯器二：LLVM和GCC的區別

GCC: GNU Compiler Collection
GCC屬於傳統編譯器，傳統編譯器的工作原理基本上都是三段式的，可以分為前端（Frontend）、優化器（Optimizer）、後端（Backend）。前端負責解析源代碼，檢查語法錯誤，並將其翻譯為抽象的語法樹（Abstract Syntax Tree）。優化器對這一中間代碼進行優化，試圖使代碼更高效。後端則負責將優化器優化後的中間代碼轉換為目標機器的代碼，這一過程後端會最大化的利用目標機器的特殊指令，以提高代碼的性能。
事實上，不光靜態語言如此，動態語言也符合上面這個模型，例如Java。Java Virtual Machine也利用上面這個模型，將Java代碼翻譯為Java bytecode。這一模型的好處是，當我們要支持多種語言時，只需要添加多個前端就可以了。當需要支持多種目標機器時，只需要添加多個後端就可以了。對於中間的優化器，我們可以使用通用的中間代碼。
這種三段式的結構還有一個好處，開發前端的人只需要知道如何將源代碼轉換為優化器能夠理解的中間代碼就可以了，他不需要知道優化器的工作原理，也不需要了解目標機器的知識。這大大降低了編譯器的開發難度，使更多的開發人員可以參與進來。
雖然這種三段式的編譯器有很多有點，並且被寫到了教科書上，但是在實際中這一結構卻從來沒有被完美實現過。做的比較好的應該屬Java和.NET虛擬機。虛擬機可以將目標語言翻譯為bytecode，所以理論上講我們可以將任何語言翻譯為bytecode，然後輸入虛擬機中運行。但是這一動態語言的模型並不太適合C語言，所以硬將C語言翻譯為bytecode並實現垃圾回收機制的效率是非常低的。
GCC也將三段式做的比較好，並且實現了很多前端，支持了很多語言。但是上述這些編譯器的致命缺陷是，他們是一個完整的可執行文件，沒有給其它語言的開發者提供代碼重用的介面。即使GCC是開源的，但是源代碼重用的難度也比較大。
LLVM: Low Level Virtual Machine
LLVM最初是[Low Level Virtual Machine]的縮寫，定位是一個虛擬機，但是是比較底層的虛擬機。它的出現正是為了解決編譯器代碼重用的問題，LLVM一上來就站在比較高的角度，制定了LLVM IR這一中間代碼表示語言。LLVM IR充分考慮了各種應用場景，例如在IDE中調用LLVM進行實時的代碼語法檢查，對靜態語言、動態語言的編譯、優化等。
LLVM與GCC在三段式架構上並沒有本質區別。LLVM與其它編譯器最大的差別是，它不僅僅是Compiler Collection，也是Libraries Collection。舉個例子，假如說我要寫一個XYZ語言的優化器，我自己實現了PassXYZ演算法，用以處理XYZ語言與其它語言差別最大的地方。而LLVM優化器提供的PassA和PassB演算法則提供了XYZ語言與其它語言共性的優化演算法。那麼我可以選擇XYZ優化器在鏈接的時候把LLVM提供的演算法鏈接進來。LLVM不僅僅是編譯器，也是一個SDK。