Fuzz testing: integrate CSmith and LLVM-Stress to find parser/optimizer crashes

[yudongusa]

Background

A production compiler must not crash or silently miscompile on any valid input. Fuzzing is the most effective way to find these edge cases. Two established tools apply directly:

• LLVM-Stress (llvm-stress): generates random but syntactically valid .ll files and has historically found dozens of LLVM optimizer bugs
• CSmith: generates random C programs that, when compiled to .ll via clang, stress the optimizer and codegen with realistic patterns

Goals

Phase 1 — Parser fuzzing

• Feed the output of llvm-stress directly into our llvm-ir-parser. The parser must either accept valid IR without panicking or return a well-formed ParseError. It must never panic or produce undefined behaviour.
• Run 10 000+ iterations per CI nightly run.

Phase 2 — Optimizer fuzzing

• Parse each llvm-stress output, run all optimization passes, and compare the printed IR round-trip. Panics and assertion failures are bugs.

Phase 3 — Codegen fuzzing

• For modules that parse and optimise cleanly, run x86-64 codegen. Any panic in the codegen pipeline is a bug.

Phase 4 — Semantic fuzzing (CSmith)

• Compile random C programs with CSmith → clang → .ll
• Feed .ll into our pipeline → link and run
• Compare exit code against clang's native output
• Any mismatch is a miscompilation bug

Acceptance criteria

• fuzz/ crate using cargo-fuzz (libFuzzer backend) targeting the parser
• Nightly GitHub Actions job running llvm-stress | cargo fuzz run parser for 5 minutes
• CSmith integration script (scripts/csmith_test.sh) with at least 1 000 random programs
• All discovered crashes fixed before closing this issue (track sub-issues)

References

• cargo-fuzz
• CSmith
• llvm-stress