减少GCC优化错误的ARMv7裸机C++编码指南咨询

-O0与-O1的运行行为差异几乎不会是GCC本身的bug，绝大多数是代码中的未定义行为、不符合C/C++标准的硬件访问写法在优化开启后被触发，优先排查以下高频场景：

• 缺失volatile限定：所有内存映射外设寄存器、中断服务函数与主循环共享的全局/静态变量，必须加volatile修饰。-O0等级下编译器不会将变量缓存到通用寄存器，每次访问都会直接读写内存，因此不会暴露问题；-O1开启后，编译器会将非volatile变量缓存到寄存器、直接删除判定为“无副作用”的寄存器写操作，会导致寄存器配置失效、共享变量状态不同步，是嵌入式场景优化后跑飞的第一大原因。
• 未定义行为（UB）触发：重点排查数组越界写、未初始化栈/堆变量使用、有符号整数溢出、空指针解指、违反严格别名规则的指针强转。-O0下编译器不会做激进的指令重排、死代码消除，栈空间也会预留更多冗余填充，大部分未定义行为不会触发故障；-O1下编译器默认基于“代码不存在未定义行为”的假设做优化，越界写可能覆盖栈上的函数返回地址、关键寄存器保存值，运行到触发条件就会直接跑飞导致调试器断连。

  快速验证方法：给编译选项加-fno-strict-aliasing后用-O1编译，如果程序运行正常，基本可以确定代码中存在违反严格别名规则的非法类型转换。

• 栈溢出：不要用-O0下的栈占用估算栈空间大小。-O1虽然单函数栈帧更小，但会开启函数内联、尾调用优化，中断嵌套场景下的栈峰值占用可能高于-O0配置，运行1-2分钟刚好触发最深调用路径时栈溢出，会直接破坏向量表、内核寄存器状态导致挂死。可以先将栈空间放大2倍做验证测试。
• 时序裕量不足：-O1生成的代码运行速度远高于-O0，原本靠-O0执行速度凑出来的软延时、外设轮询等待逻辑会失效，比如Flash擦写等待周期不足、SPI/I2C通信时序不满足外设要求、外设上电后等待时长不够，运行过程中累计触发总线错误直接进入HardFault。

• 硬件访问层做统一封装：所有内存映射寄存器的定义必须带volatile限定，禁止业务代码直接强转整数地址访问寄存器，寄存器结构体定义参考如下写法：

  // 符合ARMv7访问要求的寄存器定义
  typedef struct {
      volatile uint32_t CR;
      volatile uint32_t SR;
      volatile uint32_t DR;
  } UART_RegDef;
  #define UART1 ((UART_RegDef*)0x40013800UL)
  

• 跨执行流共享变量做合规处理：中断与主循环、多任务间共享的状态变量、标志位除了加volatile，还要保证访问原子性：ARMv7架构下自然对齐的32位变量访问是原子的，更小位宽的变量访问时要临时关中断或者用原子操作实现，不要依赖编译器保证访问原子性。
• 编译器告警全量开启并作为错误处理：编译时固定加-Wall -Wextra -Werror -Wuninitialized -Warray-bounds选项，不要手动屏蔽默认告警，80%以上的未定义行为会在编译阶段被告警捕获。
• 不写依赖编译器非标准行为的代码：不要用无副作用的空循环实现延时，这类循环在-O1下会被编译器直接删除，延时要使用编译器内置延时函数或者带volatile计数变量的循环；需要做类型双关时用memcpy或者C++17标准的std::bit_cast，不要直接做跨类型指针强转违反严格别名规则。
• 基础配置与优化等级解耦：链接脚本、启动文件中的栈、堆大小不要基于单个优化等级的测试结果设置，至少预留30%的冗余空间；中断向量表、代码段、RAM段的链接地址严格按照ARMv7要求做4/8字节对齐，不要依赖编译器自动对齐。
• 故障排查机制前置：开启ARMv7内核的HardFault、MemManageFault、BusFault、UsageFault异常入口，在异常处理中保存故障现场的PC、LR寄存器值、栈帧信息，不需要等调试器断连就能定位到故障触发的代码位置，比全量重构效率高一个数量级。
• 定位具体优化触发点时，不需要全量回退优化等级，可以逐个开启-O1包含的优化子项，定位到具体触发故障的优化pass后反向排查对应代码逻辑，排查成本远低于全量重构。

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