GCC 編譯器優化陷阱：const 變數被常數傳播導致指標修改失效

現象重現

int main() {
    const int a = 1;
    int *b = (int*)&a;
    *b = 21;
    printf("%d, %d\n", a, *b); // 輸出: 1, 21  (!!)
    return 0;
}

預期 a 被修改為 21，實際輸出 1, 21。地址相同，值卻不同。

組合語言揭秘

// GCC -O2 x86-64 AT&T 語法
main:
    subq    $8, %rsp
    movl    $1, -4(%rsp)      # a = 1 存入堆疊
    movl    $21, -4(%rsp)     # *b = 21 寫入同一地址
    movl    $1, %esi          # printf 參數 a: 直接用常數 1！
    leaq    -4(%rsp), %rdi    # printf 參數 *b: 取地址值 (21)
    call    printf
    xorl    %eax, %eax
    addq    $8, %rsp
    ret

關鍵點：movl $1, %esi — 編譯器將 a 視為編譯期常數，直接內嵌到 printf 參數，完全忽略記憶體實際值。

根因：常數傳播優化

• const int a = 1：初始值為編譯期常數。
• GCC 假設 const 物件**不會被修改**（嚴格別名規則 + const 語義）。
• 優化階段執行常數傳播：所有讀取 a 的地方替換為常數 1。
• 透過指標修改 a 屬於未定義行為（違反 const 契約），編譯器不保證行為一致。

驗證：阻止常數傳播

int main() {
    int c = 1;               // 非常數初始化
    const int a = c;         // 執行期賦值
    int *b = (int*)&a;
    *b = 21;
    printf("%d, %d\n", a, *b); // 輸出: 21, 21 ✓
}

對應組合語言會正確從堆疊讀取 a 的值（movl -4(%rsp), %esi）。

標準視角：C 標準如何規定？

• C99 6.7.3/5：試圖修改 const 修飾的物件 → **未定義行為**。
• C99 6.7.3/6：const 僅承諾程式碼不直接修改；不保證物件在記憶體中不可變（可能在 ROM、受保護頁面）。
• 編譯器有權假設 const 物件不變，進行激進優化（常數傳播、死碼消除、環狀緩衝區優化等）。

實務避坑指南

1. 絕不透過非常數指標修改 const 物件。需修改時，去掉 const 或使用 mutable (C++ 類成員)。
2. 硬體暫存器映射：用 volatile 而非 const。
   volatile uint32_t *REG = (volatile uint32_t*)0x40000000;
3. 共享記憶體/多執行緒：用 volatile 或原子操作（std::atomic、GCC builtins）。
4. 嵌入式只讀配置表：const + __attribute__((section(".rodata"))) 確保進入 Flash，不可修改。
5. 除錯時查看組合語言：gcc -S -O2 -fverbose-asm 確認優化行為。

延伸：其他常見優化驚喜

結語

const 是給**編譯器**和**讀程式碼的人**的承諾，不是執行期鎖。違反承諾（透過指標修改）會觸發未定義行為，編譯器優化會讓結果「不可思議」。嵌入式開發中，正確使用 const/volatile/restrict，比依賴編譯器「智能」可靠得多。