Clang -O2/-O3 下程序崩溃源于未定义行为（UB）被优化器放大，如数组越界、有符号溢出等；建议用 -fsanitize=address 和 -fsanitize=undefined 检测，并检查循环边界。
Clang -O2/-O3 下程序崩溃，先查未定义行为
优化本身不制造 Bug，但它会放大代码里原本“凑巧没出事”的未定义行为（UB）。比如数组越界、有符号整数溢出、空指针解引用、未初始化变量读取——这些在 -O0 下可能“碰巧”跑通，但 -O2 或 -O3 会基于“假设代码无 UB”做激进变换，导致行为突变。
实操建议：
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
- 用
-fsanitize=address和-fsanitize=undefined重新编译运行，能直接定位越界、溢出、未初始化等底层问题 - 检查循环边界：常见错误是
for (int i = 0; i （应为 <code>i ），<code>-O3可能将该循环向量化，越界访问立刻暴露 - 禁用优化临时验证：
clang -O0跑一遍，如果正常，基本锁定是优化暴露了 UB
Clang -Oz 导致寄存器复用错乱怎么办
-Oz 是体积优先的极端优化，它极度压缩指令数和寄存器使用，在 ARM/Thumb 等架构上容易引发寄存器生命周期管理错误。典型现象是变量值在函数中间被意外覆盖，尤其出现在指针运算、多步计算或紧凑循环中。
实操建议：
- 立即停用
-Oz，改用-Os（平衡体积与可靠性）或-O2 - 对比汇编输出：
clang -S -Oz main.c和clang -S -Os main.c，重点看关键变量（如长度字段、索引变量）是否被复用同一寄存器且未妥善保存 - 对敏感函数加
__attribute__((optimize("O2")))局部降级，避免全局-Oz污染
静态分析警告变多，不是误报而是优化暴露了隐患
启用 -O2 后再跑 clang --analyze，常会新增大量“Use after free”“Uninitialized value”类警告。这不是分析器变严了，而是优化改变了控制流或内联了函数，让原先隐藏的路径变得可分析。
实操建议：
- 不要忽略新增警告——尤其是涉及指针生命周期和条件分支的，它们往往对应真实风险点
- 用
-Xanalyzer -analyzer-config report-in-main-source-file=true把报告聚焦到你写的源文件，过滤掉系统头文件干扰 - 对已知安全但触发警告的代码，用
__attribute__((analyzer_noreturn))或__builtin_assume()显式告知分析器，而非直接 suppress
Dev-C++ 中 Clang 编译成功但运行报错，环境链路要拆开验
IDE 封装掩盖了真实执行环境。Clang 编译通过，只说明语法和链接没问题；运行时报错（如 segmentation fault、dll not found）大概率是运行时依赖或 IDE 模拟终端的问题。
实操建议：
- 找到生成的
.exe，在 CMD 或 PowerShell 中直接运行，绕过 Dev-C++ 的运行封装 - 用
ldd your_program.exe（Windows 上可用Dependencies.exe）检查缺失的 DLL，特别是libclang_rt.builtins-x86_64.dll这类 sanitizer 运行时库 - 确认 Dev-C++ 的 Clang 配置中，“编译后运行”选项没勾选“使用 IDE 自带的 MinGW 控制台”，这会导致环境变量丢失
