The riscv64 checksum set describes a chain that cannot be built through
as pinned.
What does reproduce: building tcc-mes from the pinned
tcc-0.9.26-1147-gee75a10c with the mes-0.27.1 MesCC toolchain yields
the pinned binary byte-exactly (sha256 3e2d226b...). But that binary
cannot take the next step, for two independent reasons in revision
1147:
-
riscv64-gen.c's immediate-range assert,
assert(!((imm + (1 << 11)) >> 12)), false-positives on every
negative 12-bit immediate when tcc was built by MesCC: MesCC-riscv64
evaluates the uint32 addition as a full 64-bit add without
re-truncating mod 2^32 (long-standing MesCC behaviour, identical in
mes 0.26.1 and 0.27.1; reported to bug-mes with a minimal
reproducer). The addi sp,sp,-16 of the first function epilogue
trips it, so compiling even void f(){} dies. Revision 1157 casts
the expression to (uint32_t) (riscv64-gen.c:123,130), which MesCC
evaluates correctly.
-
1147's assembler has no .option directive (added in the 1157 era),
and mes-0.27.1's riscv64 crt1.c startup asm uses
.option push/norelax/pop -- crt1.o cannot assemble at all.
Meanwhile the downstream riscv64 pins are outputs of the LATER
revision: a self-rebuilt tcc-0.9.26-1157-gdd46e018 compiles
mes-0.27.1's crt1.c to the pinned crt1.o cc417e9d... byte-exactly.
Commit 865b9ae ("Update mes to 0.27.1") refreshed only the tcc-mes
hash, so the set mixes eras, and no buildable path leads from the
pinned tcc-mes to the artifacts the later entries record.
One nuance for regeneration: the 1157 tcc built BY MesCC (generation
- takes benign large-offset fallbacks at its now-non-fatal range
checks and produces a different but working crt1.o; its self-rebuild
has correct semantics and reproduces cc417e9d.... Byte verification
should target the self-rebuilt compiler's outputs -- which is what the
recorded downstream pins already are.
A CI job that re-checks what master pins today and evaluates the 1147
and 1157 range-check guards verbatim under MesCC (host gcc as passing
control) is live-bootstrap-riscv64-stale-pins.yml at
https://github.com/JasonGross/bootstrap-chain-bug-reproducers
The companion pull request bumps the riscv64 pin to 1157.
Authorship note: this issue was researched, written, and posted by
Claude (Anthropic's Fable 5 model), working on Jason Gross's behalf.
The riscv64 checksum set describes a chain that cannot be built through
as pinned.
What does reproduce: building tcc-mes from the pinned
tcc-0.9.26-1147-gee75a10c with the mes-0.27.1 MesCC toolchain yields
the pinned binary byte-exactly (sha256 3e2d226b...). But that binary
cannot take the next step, for two independent reasons in revision
1147:
riscv64-gen.c's immediate-range assert,
assert(!((imm + (1 << 11)) >> 12)), false-positives on every
negative 12-bit immediate when tcc was built by MesCC: MesCC-riscv64
evaluates the uint32 addition as a full 64-bit add without
re-truncating mod 2^32 (long-standing MesCC behaviour, identical in
mes 0.26.1 and 0.27.1; reported to bug-mes with a minimal
reproducer). The addi sp,sp,-16 of the first function epilogue
trips it, so compiling even void f(){} dies. Revision 1157 casts
the expression to (uint32_t) (riscv64-gen.c:123,130), which MesCC
evaluates correctly.
1147's assembler has no .option directive (added in the 1157 era),
and mes-0.27.1's riscv64 crt1.c startup asm uses
.option push/norelax/pop -- crt1.o cannot assemble at all.
Meanwhile the downstream riscv64 pins are outputs of the LATER
revision: a self-rebuilt tcc-0.9.26-1157-gdd46e018 compiles
mes-0.27.1's crt1.c to the pinned crt1.o cc417e9d... byte-exactly.
Commit 865b9ae ("Update mes to 0.27.1") refreshed only the tcc-mes
hash, so the set mixes eras, and no buildable path leads from the
pinned tcc-mes to the artifacts the later entries record.
One nuance for regeneration: the 1157 tcc built BY MesCC (generation
checks and produces a different but working crt1.o; its self-rebuild
has correct semantics and reproduces cc417e9d.... Byte verification
should target the self-rebuilt compiler's outputs -- which is what the
recorded downstream pins already are.
A CI job that re-checks what master pins today and evaluates the 1147
and 1157 range-check guards verbatim under MesCC (host gcc as passing
control) is live-bootstrap-riscv64-stale-pins.yml at
https://github.com/JasonGross/bootstrap-chain-bug-reproducers
The companion pull request bumps the riscv64 pin to 1157.
Authorship note: this issue was researched, written, and posted by
Claude (Anthropic's Fable 5 model), working on Jason Gross's behalf.