make test-corpus currently fails on a clean main (ab24384), independent of any cc370 change: 74 modules CHANGED against as370/tests/corpus/libc370.manifest, 7 assembling modules absent from it (manifest covers 737, 744 non-wip on disk).
Found while validating #40/#43; verified unrelated to that fix — the failure reproduces identically with the fix stashed, and the old/new compiler emit byte-identical .s for every buildable libc370 TU.
What drifted
The gate assembles the live sibling checkout (LIBC370=../../libc370) and compares deck SHAs against a manifest last generated 2026-07-19. libc370 has simply moved on since (clean working tree @ 87e2f6e). Two components:
- 10 ×
asm/*.asm — committed hand-written sources with real changes since the manifest date (the malloc/crt work, libc370#82/#88/#91): @@crt0, @@crt1, @@crtm, @@getm, @@freem, @@svc99, @@system, @@aopen, @@aclose, @@aline.
- 64 ×
src/**/*.s — untracked build outputs of mklibc.py (51 clib, 4 time64, 3 jes, 3 racf, 2 dyn75, 1 cmtt), regenerated from C sources that evolved since 07-19.
- 7 modules absent from the manifest (coverage drift):
src/clib/{@@cas,@@ppahrv,@@stow,@@swap,@@ver,heapsp}.s, src/jes/jesprb.s.
So this is not an as370 regression — it is the known scope limitation spelled out in check.sh's header: the gate enforces stability of a frozen baseline, and the baseline's input (the libc370 tree) moves on its own schedule.
Short-term fix
Re-run sh as370/tests/corpus/check.sh --generate against the current, clean libc370 state and commit the refreshed manifest.
Structural question (feeds #23)
Any libc370 commit invalidates cc370's gate, and nothing records which libc370 state a manifest belongs to. Worth considering when doing #23-full:
- stamp the libc370 commit (+ dirty flag) into the manifest header, so a mismatch reports "baseline is for libc370 @ X, checkout is @ Y -- regenerate" instead of a wall of CHANGED lines;
- or pin/vendor the corpus inputs so the gate only moves when as370 does.
make test-corpuscurrently fails on a cleanmain(ab24384), independent of any cc370 change: 74 modules CHANGED againstas370/tests/corpus/libc370.manifest, 7 assembling modules absent from it (manifest covers 737, 744 non-wip on disk).Found while validating #40/#43; verified unrelated to that fix — the failure reproduces identically with the fix stashed, and the old/new compiler emit byte-identical
.sfor every buildable libc370 TU.What drifted
The gate assembles the live sibling checkout (
LIBC370=../../libc370) and compares deck SHAs against a manifest last generated 2026-07-19. libc370 has simply moved on since (clean working tree @87e2f6e). Two components:asm/*.asm— committed hand-written sources with real changes since the manifest date (the malloc/crt work, libc370#82/#88/#91):@@crt0,@@crt1,@@crtm,@@getm,@@freem,@@svc99,@@system,@@aopen,@@aclose,@@aline.src/**/*.s— untracked build outputs ofmklibc.py(51 clib, 4 time64, 3 jes, 3 racf, 2 dyn75, 1 cmtt), regenerated from C sources that evolved since 07-19.src/clib/{@@cas,@@ppahrv,@@stow,@@swap,@@ver,heapsp}.s,src/jes/jesprb.s.So this is not an as370 regression — it is the known scope limitation spelled out in
check.sh's header: the gate enforces stability of a frozen baseline, and the baseline's input (the libc370 tree) moves on its own schedule.Short-term fix
Re-run
sh as370/tests/corpus/check.sh --generateagainst the current, clean libc370 state and commit the refreshed manifest.Structural question (feeds #23)
Any libc370 commit invalidates cc370's gate, and nothing records which libc370 state a manifest belongs to. Worth considering when doing #23-full: