如何定位GCC11 -O3优化引入的程序运行Bug

这类问题本质是高优化级别下触发的未定义行为（UB）——插入打印这类带副作用的代码会改变编译器的寄存器分配、内存布局、优化决策，直接让UB触发条件消失，排查时不要依赖插入打印的调试方式，按以下步骤推进：

• 第一步先锁问题范围，不改动代码逻辑
  • 保留GCC11 -O3的原始编译参数，不插入任何调试代码，通过模块二分法定位：逐个将编译单元替换为GCC9编译的目标文件，找到替换后Bug消失的模块，再逐步把范围缩小到单个源文件、单个函数。
  • 快速验证UB类型：给GCC11编译选项追加-fno-strict-aliasing -fno-delete-null-pointer-checks -fwrapv，逐个开关单独测试，确认关闭哪个优化项后Bug消失。如果追加-fno-strict-aliasing后异常行为消失，可直接锁定为严格别名规则违例类问题。
• 第二步用工具定位具体代码位置，避免肉眼盲查
  • 开高等级告警扫描可疑编译单元：追加-Wall -Wextra -Wstrict-aliasing=2 -Wuninitialized编译参数，重点排查不同类型指针强制转换后解引用的代码段，-Wstrict-aliasing=2的告警误报率远低于最高等级3，参考价值最高。
  • 用未定义行为检测器跑复现场景：编译时追加-fsanitize=undefined参数，保持其余编译选项和出问题版本完全一致，运行触发Bug的路径，UBsan会直接输出严格别名违例、有符号溢出、空指针访问等UB的精确代码位置，排查效率远高于人工读码。
  • 如果运行环境不支持跑sanitizer，逐段给可疑代码块加#pragma GCC optimize ("O0")包裹，逐段降低优化级别，找到哪段代码关闭优化后Bug消失，再进一步缩小范围。禁止直接给整个项目降优化级别，会直接改变全局优化逻辑导致Bug无法复现。
• 第三步针对strict-aliasing类问题的专项核查
  • 重点排查以下高危写法：
    • 两个不兼容类型（非signed/unsigned对应变体、非char类型）的指针直接强转后解引用
    • 通过void*中转不同类型指针后直接解引用
    • 仅因起始成员偏移一致就强制转换不同结构体指针进行读写
    • 将非char类型变量的地址强转为其他类型指针访问
  • 对比两个GCC版本的优化中间结果：给可疑函数追加-fdump-tree-alias -fdump-tree-optimized编译参数，分别导出GCC9、GCC11编译时的别名分析结果、优化后IR，对比存在差异的内存访问逻辑——GCC11的别名分析逻辑比GCC9更激进，会将判定为无别名的内存访问直接删除、重排顺序，差异点就是问题触发位置。
  • 注意不要靠加volatile、插空代码、加打印的方式临时规避问题，这类操作只是干扰了优化器的判断，没有修复未定义行为，后续升级编译器、调整无关代码时Bug会再次复现。

后续已确认本次问题根因为strict-aliasing（严格别名）规则违例引发的未定义行为，这类问题排查难度极高，也是C/C++高优化级别编译下最常见的跨版本异常诱因。

内容的提问来源于stack exchange，提问作者therapyCarrots