差分测试与模糊测试：自动化发现编译器错误编译的流水线构建

编译器错误编译（miscompile）是软件工程中最隐蔽的缺陷类型之一。与导致编译器崩溃的漏洞不同，错误编译会静默生成语义不正确的可执行文件，使得开发者在排查应用程序异常时难以将问题溯源至编译器本身。近期 SemiAnalysis 发布的研究显示，通过自动化技术可以在短时间内发现数百个潜在的编译器缺陷，其中包括将原子操作降级为非原子存储的严重错误 —— 这类缺陷在生产环境中可能造成数据损坏，却极难通过传统测试手段捕获。

本文从工程实践角度，系统阐述如何利用差分测试（differential testing）与模糊测试（fuzzing）构建可复现的错误编译检测流水线，涵盖测试程序生成策略、测试预言机设计、根因定位方法及可落地的参数配置。

差分测试：错误检测的核心机制

差分测试的基本原理是利用多个 "编译轨道"（compilation track）对同一份测试程序进行编译，并比较其执行结果。当不同轨道产生不一致的输出时，即表明至少存在一个轨道存在缺陷。在编译器测试领域，编译轨道可以通过以下维度组合构建：

• 跨编译器对比：如 GCC 与 LLVM 对同一份 C 程序的编译结果
• 跨版本对比：同一编译器的不同版本（如 LLVM 14 vs LLVM 15）
• 优化级别对比：同一编译器在不同优化级别下的行为（-O0 作为基准对比 -O1/-O2/-O3）
• 目标架构对比：同一编译器针对不同后端（x86、ARM、AMDGPU）的代码生成

研究表明，约 57% 的 GCC 优化缺陷和 61% 的 LLVM 优化缺陷属于错误编译类型，而非编译器崩溃。这意味着仅依赖崩溃检测会遗漏大部分严重缺陷。

测试程序生成：从语法合规到语义有效

测试程序生成的核心挑战在于平衡有效性与多样性。程序必须语法合规且语义明确，否则会在编译前端即被拒绝，无法触及优化器与代码生成器等缺陷高发区域；同时程序必须具备足够的语言特性覆盖率，以触发各类优化路径。

生成式方法：Csmith 与 YARPGen

Csmith 是 C 编译器模糊测试的里程碑工具，其通过硬编码 C99 语法的子集，生成无未定义行为（UB-free）的随机 C 程序。Csmith 在生成过程中维护概率表，从可用变量、语句和表达式中启发式选择，能够生成包含复杂控制流、指针操作和数组访问的测试用例。据统计，Csmith 已帮助发现超过 325 个未知的编译器缺陷。

CsmithEdge 在 Csmith 基础上进一步放宽 UB 约束，通过概率方式允许生成包含潜在未定义行为的程序，然后利用动态分析工具检测 UB 位置，最终生成两个版本：保留 UB 的版本用于测试编译器对 UB 的处理能力，去除 UB 的版本用于差分测试。这种方法发现了 7 个此前 Csmith 无法检测的错误编译缺陷。

YARPGen 则引入生成策略（generation policies）机制，通过系统性地偏置概率分布，生成更有可能触发特定优化的程序，从而解决模糊测试器常见的 "饱和" 问题 —— 即长期运行后难以发现新缺陷的状态。

变换式方法：EMI 与语义保持变换

等价模输入（Equivalence Modulo Inputs, EMI）是一种程序变换技术，其核心思想是：对于给定的输入集合，如果两个程序产生相同的输出，则它们在该输入集合上等价。基于这一思想，Orion 工具通过删除未被执行的 "死代码" 来生成等价变体；Athena 进一步支持在死代码区域插入语句；Hermes 则实现了对活代码区域的语义保持变换，例如插入条件恒为假的代码块来修改控制流而不改变程序语义。

EMI 方法的优势在于生成的变体程序在语义上高度相关，当编译器对这些变体产生不一致的输出时，极大概率表明存在错误编译。

测试预言机设计：超越崩溃检测

测试预言机（test oracle）是判定测试是否通过的标准。对于编译器测试，常见的预言机策略包括：

差分测试预言机

裁判模式（Referee）：选择一个高质量、经充分测试的编译器版本（如 GCC 稳定版）作为基准，被测编译器的结果与之对比。

无优化基准模式（Oracle）：使用 -O0（禁用优化）作为基准，对比优化后的执行结果。由于优化不应改变程序语义，任何差异都表明优化器存在缺陷。

投票模式（Voter）：收集多个编译轨道（不同版本、不同优化级别、不同架构）的结果，以多数一致的结果作为正确结果。Csmith 采用此策略，在实践中从未发现 "分裂投票"（无明确多数）的情况。

蜕变测试预言机

蜕变测试（metamorphic testing）通过构造语义等价的程序变体来检测缺陷。例如，将表达式 e1 + e2 改写为 e2 + e1，或将 e * 2 改写为 e + e。如果编译器对这些等价变体产生不一致的输出，则存在缺陷。

构建检测流水线：工程实践要点

基于上述原理，一个可落地的错误编译检测流水线应包含以下组件：

1. 测试程序生成器配置

# 生成策略参数示例
generation:
  strategy: "grammar-based"  # 或 "transformation-based"
  ub_handling: "strict"      # "strict" | "relaxed" | "detect-and-scrub"
  max_program_size: 1000     # 行数限制
  feature_weights:
    loops: 0.3
    pointers: 0.25
    arrays: 0.25
    arithmetic: 0.2

2. 编译轨道矩阵

建议至少配置以下编译轨道组合：

3. 结果比对策略

• 输出比对：比较标准输出、返回值、浮点结果（考虑精度容差）
• 内存轨迹比对：对于内存模型相关测试，对比内存访问轨迹
• 性能退化检测：监控优化后程序是否出现意外的性能下降

4. 误报过滤

使用 sanitizers（AddressSanitizer、UndefinedBehaviorSanitizer）和形式化验证工具（如 Alive2 用于 LLVM IR 验证）过滤由测试程序自身未定义行为导致的误报。

根因定位：从见证程序到修复

发现潜在缺陷后，需要最小化测试用例（test case minimization）以生成 "见证程序"（witness program）。典型的最小化流程包括：

1. 语法级简化：使用工具（如 C-Reduce）删除不影响复现的代码行
2. 语义级简化：识别触发缺陷的最小语言特性组合
3. 编译选项隔离：确定触发缺陷的最小优化选项集合
4. 缺陷分类：根据症状（崩溃、错误结果、性能退化）和根因（前端、中端优化、后端代码生成）分类

研究表明，约 80% 的缺陷揭示测试用例少于 45 行代码，且大多数修复仅修改单个源文件。这意味着高效的模糊测试不需要生成过于复杂的程序。

新兴趋势：AI 辅助的错误发现

近期实践表明，大语言模型（LLM）正在改变编译器测试的经济学。通过部署多个子代理并行分析编译器源码，可以在数小时内发现传统模糊测试需要数周才能发现的缺陷类别。特别值得注意的是，AI 代码审查能够发现模糊测试难以触及的缺陷类型 —— 例如原子操作相关的错误编译，这类缺陷在 99% 的场景下表现正常，仅在特定并发条件下导致数据损坏。

然而，AI 辅助发现与模糊测试具有互补性：模糊测试发现的缺陷通常是可复现的错误编译，确定性高；AI 发现的缺陷则需要人工验证，但能够覆盖模糊测试难以生成的代码模式。

结论

构建有效的编译器错误编译检测流水线需要在测试程序生成、预言机设计和根因定位三个层面进行系统化设计。差分测试提供了检测错误编译的理论基础，而现代模糊测试工具（Csmith、YARPGen）和变换技术（EMI）则提供了工程实现路径。随着 AI 辅助测试技术的发展，编译器测试正从 "资源密集型" 向 "计算密集型" 转变，但无论技术如何演进，生成有效测试程序与设计可靠预言机始终是编译器测试的核心挑战。

参考来源

• Lebar, Justin. "Finding Miscompiles for Fun, Not Profit." SemiAnalysis Newsletter, May 2026.
• Chen, Junjie, et al. "A Survey of Modern Compiler Fuzzing." arXiv:2306.06884, 2023.
• Even-Mendoza, Karine, et al. "CsmithEdge: More Effective Compiler Testing by Handling Undefined Behaviour Less Conservatively." Empirical Software Engineering, 2022.

compilers