GCC 重新挑戰 WebAssembly 後端
GCC 提出新的 WebAssembly 後端 RFC patch series。這篇整理它的進度、缺少的功能、和 LLVM/Clang 的差距。
GCC 這次提出新的 WebAssembly 後端 RFC，代表 GNU 編譯器又開始碰 WASM 了。
說真的，這案子拖很久了。GCC 這次的 patch 大約 3,000 行，狀態還是 RFC。也就是說，它還在收意見，離正式合併還有一段路。
你可能會想問，這有什麼好寫的。答案很簡單，WebAssembly 幾乎一直是 Clang 和 LLVM 的地盤。現在 GCC 想回來搶一席，這件事本身就很有看頭。
| 項目 | 內容 |
|---|---|
| Patch 規模 | 約 3,000 行程式碼 |
| 目前狀態 | RFC，尚未核准 |
| 缺少功能 | reference types、tables、exceptions、debug info、data sections |
| 上次相關嘗試 | 接近 10 年前 |
這個提案為什麼重要
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
先講白的。GCC 不是沒人用。它在 Linux、嵌入式、系統軟體圈，還是很有份量。若它能補上 WebAssembly 後端，開發者就多一條路，不用全都擠在 LLVM 這條線上。
這件事對 C 和 C++ 開發者特別有感。很多人本來就熟 GCC 的旗標、診斷訊息、建置流程。若能直接把這套工作流搬到 WASM，切換成本會低很多。
但現實也很直接。LLVM 早就把 WebAssembly 生態做起來了。它有 LLVM 專案 的完整後端工作，也有更成熟的社群節奏。GCC 現在要追，不能只靠一句「我們也要做」。
- WebAssembly 已經能跑瀏覽器和伺服器工作負載
- GCC 支援會讓編譯器選擇更多
- RFC 階段表示功能還很早期
- LLVM 目前仍是主流路線
這份 patch 到底做了什麼
這次的提案是 request for comments。講白了，就是先丟出來讓大家挑毛病。這種狀態很正常，因為後端最怕的不是「沒做完」，而是「方向錯了卻一路做下去」。
目前已知的內容不算多，但缺口很清楚。它還沒有 reference types、tables、exceptions、debug info 和 data sections。這些都不是裝飾品。它們直接影響能不能拿來做真實專案。
如果少了 debug info，除錯會很痛。少了 exceptions，很多語言綁定和 runtime 整合也會卡住。少了 data sections，實務上的模組佈局也不完整。講白了，現在比較像「先把骨架搭起來」。
“Nearly a decade ago there was a proposal for a GCC WebAssembly back-end that ultimately never ended up being merged.” — Michael Larabel, Phoronix
這句話很準。Phoronix 的 Michael Larabel 把歷史講得很直白。GCC 不是第一次碰 WASM，但上一次沒走到最後。
所以這次的重點，不是能不能發 patch。重點是，這條線能不能被持續維護。後端開發最怕半途斷電。尤其是像 WebAssembly 這種還在演進的目標。
GCC 和 LLVM 怎麼比
如果只看現況，LLVM 還是贏面大。它在 WebAssembly 的支援比較完整，工具鏈也比較成熟。很多想把 C、C++ 編到 WASM 的團隊，第一個想到的還是 Clang。
但 GCC 也不是沒優勢。它在傳統 native 編譯場景很穩，特別是 Linux 世界。對一些團隊來說，能少換一套編譯器，真的省很多事。
我覺得這裡最值得看的，是兩邊的開發哲學。LLVM 比較像快速推進，GCC 比較像保守穩定。前者適合搶新目標，後者適合把既有生態吃乾抹淨。WebAssembly 這種新平台，前期通常是 LLVM 先衝。
- LLVM/Clang 的 WASM 支援較成熟
- GCC 在 native 編譯與 Linux 生態很強
- GCC 若補上 WASM，會多一個可比較的工具鏈
- 團隊可比較 codegen、診斷和建置整合
還有一個很現實的問題。誰來維護。後端不是丟上去就結束。它要跟 ABI、除錯、runtime、runtime library 一起跑。這些東西都需要人力，而且是長期人力。
所以這次 RFC 的價值，不在於它已經完成多少。它的價值在於，它讓社群可以直接討論：GCC 值不值得在 WASM 再投一輪資源。
這件事放在產業脈絡裡看
WebAssembly 原本是瀏覽器技術。現在它早就不只在瀏覽器裡混。伺服器端、edge runtime、插件系統，甚至某些安全沙盒場景，都開始用到 WASM。
這種轉變很關鍵。因為一旦 WASM 變成通用執行環境，編譯器選擇就不只是「能不能編」。它還會影響效能、除錯體驗、工具鏈整合，還有團隊既有的建置習慣。
GCC 這次的提案，剛好踩在這個交叉點上。它不是在做一個純學術玩具，而是在碰一個已經進入實務層的目標平台。這也是為什麼它會被拿來跟 LLVM 比，而不是只當成一篇 mailing list 討論。
如果你是做 C、C++、系統軟體，這件事值得追。不是因為它一定會成功，而是因為它會告訴你，WebAssembly 的編譯器版圖還有沒有第二條主線。
接下來要看什麼
下一步很簡單。先看 GCC Steering Committee 會不會接球。再看 patch series 會不會繼續長大。現在只有約 3,000 行，功能缺口又不少，離能用還早。
如果後續 review 順利，這案子就會從「有人試著做」變成「社群開始認真談整合」。到那時候，討論重點會變成 ABI、debug、exceptions，還有 GCC 要怎麼跟 LLVM 拉開差異。
我的判斷是，這案子短期內不會立刻改變市場。可是一旦它真的往前走，對開發者來說會很實際。你會多一個可選的 WebAssembly 編譯器，也多一個能比較的工具鏈。
如果你平常有在看 GCC patch 或 WASM 工具鏈，現在就可以把這條線加進觀察清單。接下來幾個月，才是看它會不會真的往前走的時間。