1樓：
靜態、動態分析，fuzzer等自動測試工具無法滿足我的需求：
* custom的「指令選擇」
[llvm-dev] Options for custom CCState, CCAssignFn, and GlobalISel
* 基於HEA演算法的「圖染色」
[llvm-dev] Register Allocation Graph Coloring algorithm and Others
* 指令排程 ILP
[llvm-dev] How to get started with instruction scheduling? Advice needed.
我的「土方法」：跑llvm/test/CodeGen/RISCV測試用例，沒過的測試一條一條找root cause，以GNU工具鏈為「標答」，LLVM產生的彙編和GNU的diff，有不同的也得一條一條「指令」、乙個乙個「暫存器」找
D41653 [RISCV] Initial porting GlobalISel
但如果GNU的結果也是錯的呢？模擬器有BUG呢？希望有自動化工具能讓我從土、笨、Lowering方法上解放出來，以上 :)
2樓：
如果能成功編譯一兩個大專案的話基本上99.9999%的bug都沒有了，現在主要問題不是編譯器，而是framework中的某些細小bug，這些反而更致命
3樓：
@藍色大大講到的test buckets，以及@熊英飛老師講到的學術界的一些新方法，他們說的都比較詳細了。
我還想補充一點，就是編譯gcc時用到的bootstrap，詳細見gcc官方wiki.
4樓：朱沚汀
這篇文章的technique發現了兩百多個gcc+clang的bug.
5樓：峰峰真人
編譯器測試是很難的，首先不同於一般軟體，錯誤有兩種，編譯時錯和執行時錯，而且還很容易死鎖。不光要測正確性，還要測效能。效能測試的標準有時候真的很多，而正確性測試要包含各種極端和複雜的情況。
乙個編譯器的要求高，所以自身複雜性就高，於是就需要更多測試。
具體的測試內容有自帶的單元測試，語言特性測試，隨機測試，各種測試集的效能，等等。
由於以上種種，編譯器的內部實現最好敏感於各種異常情況，有不對馬上崩潰，因為編譯時錯比執行時錯實在是好太多。
6樓：wave
分正確性測試和效能測試
正確性可以用各種隨機生成的code，看最後結果是不是正確，有一定生成規則。
效能測試就是各種跑分軟體，具體每個優化有沒有生效，還可以加focus case。
7樓：藍色
還是主要是跑Test Buckets，如C++的話，就會有編譯類，執行類，效能類等。編譯類的話，就會有是否可以編譯通過，是否會報指定的資訊等，這一步驟主要是用於語法層面的測試，尤其是C++11出來後。執行類主要指跑出來的結果是否符合預期，如最後的結果，返回值等。
效能類的話，主要是跑這個程式所消耗的時間，乃至記憶體等，一般是跑SPEC（比如SPEC2006），這個一般會跑很久，我跑SPEC都是開個screen，然後讓它自動跑。正是如此，Test Buckets需要足夠的大，足夠的豐富，乃至千奇百怪，而正是如此，甚至有專門賣這樣的Test Buckets的，比如Glen McCluskey C++ Test Buckets，看了這個Test Buckets，我都在佩服寫這個的人，是怎麼想出來這些奇葩Case的。
汽車的視線是如何進行測試的？
盧元甲 真慚愧，總布置工程師居然不知道法規檢查時具體怎麼測量的 等我查下法規補充上。但設計方法還是知道的。根據國標標準，或者設計目標，通過R點位置和靠背角數值可以確定下眼點 V2點 然後通過V2點就可以做視野線，來限制造型的型麵。因此在設計過程中，視野是硬點，是車輛設計基本要求而不是後期測量出來的。...
編譯器內部是如何處理 C 語言 typedef 關鍵字的？
甄爍華 你知道貝塞斯達嗎？就是做輻射系列和上古卷軸的那個遊戲公司。他裡面專門有乙個招的職位就是C工程師。之前還嘗試過STM8標準下的C語言開發 英文直翻不知道這樣稱呼是否準確 做乙個能自動包裝的機器。這個project現在還在做。做下來的感覺就是在操控硬體 顯示全部 阿爾伯特 編譯器內部是如何處理這...
編譯器如何處理 printf 這種語言自帶的函式？
豆芽 語言其實是個規範。如果要讓使用某個語言開發的程式要跑起來，除了編譯器，還得有工程技術支援，和語言擴充套件 庫 工程技術，比如程式執行時支援 程序載入技術 os介面對接等等 從題主的描述來講，我懷疑題主書都沒看就上來問問題。首先，printf不是語言自帶的函式。然後在parser之後的過程中，在...