How we verify

Compiler correctness claims are cheap. This page describes what actually runs, so you can judge how much weight the claims on this site carry.

The corpus

Each program carries a manifest declaring what to compile, how, and what to expect. One program declares many runs — a typical execution test declares twelve, covering six optimization configurations across both architectures. That is what the test-case figure counts.

Categories cover execution output, intermediate-language shape, generated assembly, expected compile errors, debugger behaviour, and export determinism.

Axes under test

Programs are not merely run once and diffed. They are swept across:

• Optimization profiles — debug, checked, release
• Individual passes — constant folding, peephole, inlining, loop optimization, SSA versus direct lowering, graph versus stub allocation
• Architecture — x86_64 and AArch64
• String encoding — UTF-8 and UTF-32, which is a per-binary property
• Deployment class — including the fixed-arena allocator
• Carrier count — single and multicore

Optimizer statistics are themselves pinned as expectations. If a change causes the inliner to decline a site it used to accept, or the peephole pass to fire a different number of times, the suite notices — so a silent performance regression is a test failure rather than something discovered in a benchmark months later.

The merge gate

Nothing merges without the full ladder, which runs three suites concurrently in isolated workspaces:

1. Stress — the full corpus through the compiler binary.
2. Direct lowering — the same corpus through the legacy non-SSA path, kept green deliberately as a differential oracle against the SSA path. Two independent lowerings that must agree is a strong check on both.
3. Race — the corpus through an in-process driver with Go’s race detector armed, which is the only mode that puts the compiler’s own concurrency under scrutiny.

A fourth sequential gate sweeps the multicore corpus for equivalence against the sequential build. The gate passes only if every suite does.

A compiler warning fails the suite. There is no accumulating backlog of tolerated diagnostics.

Quality gates inside the compiler

Separately from tests, the compiler validates its own invariants at three checkpoints: after semantic analysis, after intermediate-code generation, and after placement. These are not assertions left in by accident — they exist to root-cause internal compiler errors at the phase that introduced them rather than at the phase that tripped over the result.

Figures as of 2026-07-22, compiler 6.7.0. Gate results from the most recent release record: stress 7635/0, direct lowering 7555/0, race 7555/0, multicore 204/204.