Proving our own gate can fail — the tamper control, reproduced on a compiler six versions away

There are two things you can say about a check. The first is it passed. The second, much harder one, is and here is what it looks like when it fails.

Almost every lab publishes the first. This entry is the second, for the check that the whole QUANTA compiler rests on.

The positive result — the compiler compiles itself, byte for byte

✅Shipped & measured

The compiler compiles its own source, then the binary that produced compiles the same source again. If the language and the compiler are self-consistent, those two outputs are identical — not equivalent, identical.

$ ./qc2
   [fixpoint-stage1] qcc15(QCC15_SRC): 75815 bytes, 39 fns, entry=74128
   [fixpoint-stage2] binary_A(QCC15_SRC): 75815 bytes, 39 fns, entry=74128
   [FIXPOINT] BYTE-IDENTICAL ✓  75815 bytes match exactly
   [build_demo] ELF exit code: 55 (want 55, fib(10)) ✓
 QCC16: 2/2 ✓ PASS

The interesting part is not the ✓. It is that this output was reproduced field for field on gcc 15.2.0, against a record made on gcc 9.4.0 — six major compiler versions and a different host apart. Same 75,815 bytes. Same 39 functions. Same entry offset. Same demo exit code.

The negative control — the same check, made to fail on command

✅Shipped & measured

A check that always passes and a check that cannot fail produce the same screenshot. So the compiler carries an environment variable whose only job is to corrupt its own intermediate output by one bit, and prove the comparison bites.

$ QCC16_TAMPER=40000 ./qc2
   [FIXPOINT] NEGATIVE CONTROL: flipped bit 0 of stage-3 byte 40000
   [FIXPOINT] MISMATCH ✗  bytes_A=75815 bytes_B=75815 entry_A=74128 entry_B=74128
   First mismatch at byte 40000: A=0xff B=0xfe
 QCC16: 1/2 ✗ FAIL

Read what it reports. The two outputs are still the same length — 75,815 bytes each — and still have the same entry offset. Nothing structural changed. The check found the difference anyway, at exactly the byte we corrupted, and it names the value it expected and the value it got: A=0xff B=0xfe.

That run was also reproduced exactly, on the same six-versions-away compiler: every byte and every count.

Alongside it sits a suite of sixteen control files — fifteen deliberately broken copies of real chapters plus one PTX truncation control — each of which must return rc=1. When they all do, the suite prints the only line in this codebase we would put on a poster:

 ✅ THE GATE CAN FAIL

What this claim is, and what it is not

🔬Research

It is worth being precise about the boundary, because there is a neighbouring claim that would be false.

The binary's sha256 is not reproducible. The recorded hash was produced on gcc 9.4.0; a gcc 15.2.0 build of the same source produces a different one. That is ordinary — binaries are toolchain-bound — but it means the hash of qc2 must never be published as a reproducibility claim, and it is not one here.

What reproduces is the compiler's own output identity: 75,815 bytes, 39 functions, entry 74128, on two independent compilations, on two independent toolchains, plus the tamper control that proves the comparison is real. That is the claim, it is narrower than "reproducible build", and it is the one we can defend line by line.

And it does not prove the gate is sound. That the gate is tested rather than proven sound is the named core gap on the QUANTA research lane, and nothing on this page closes it.

Why we lead with the failure

The question a technical buyer actually asks is not how fast is it. It is how would you know if it were broken. A gate you cannot demonstrate failing is a decoration. This is the command that makes ours fail, the byte it fails at, and the exit code that will fool you if you let it.