Acted on T46's verdict (K8/RC-4 local-alloc tying, lever = C-level lifetime shaping) instead of the
refuted allocation/permuter framings.
THE LEVER WORKS. Cluster B is `q = (Trk *)((u8 *)e + 0x3C)` landing in $a2 where the target uses $a0,
because arg0's last use (`self = arg0`) sat BELOW q's birth, keeping $a0 live so K3 first-fit pushed
q to the next free reg. Moving `self = arg0` above q's birth ELIMINATES cluster B in both placements
tried -- byte-measured:
baseline A=4 B=2 C=2 D=5 -> 13
(a) self at top A=7 B=0 C=2 D=5 -> 14
(b) self after e A=7 B=0 C=2 D=5 -> 14
BUT IT COSTS 3 POSITIONS IN A, AND THE COUPLING IS ALREADY DOCUMENTED in the draft's own header:
cluster A is a sched2 LUID tie COUPLED to lever 3 -- st1 must stay a decl-initializer (moving it into
the body forfeits the update_equiv_regs live-length doubling at local-alloc.c:1064, allocno priority
explodes, callee-saved bank rotates, frame 0x40->0x48, measured over 12 permutations), while st2/ext
must sit in the body after the index chain AND the `self = arg0` copy to reproduce the target's
save/init interleave. Moving `self = arg0` is exactly the statement that interleave is anchored on.
VERDICT: a THIRD two-knobs-one-screw in this function. st1's LUID is pinned by allocno priority ->
pins the save/init interleave (A) -> pins where `self = arg0` may sit -> decides whether q gets $a0
(B). Any future attempt must optimise A and B TOGETHER; fixing either alone is provably a wash.
Not banked, nothing regressed (draft-side only, tree clean). Cluster B has moved from an unexplained
register 2-swap to solved-but-priced-at-3-positions-in-A. Variants at .run/near6/g734_{a,b}.c.
Effort ledger recorded: Fable5 pass, wave agent (~2.6M tok, 217->13), 32-min permuter (flat),
reg_renumber oracle (framing refuted), this grind. 51,198 ins; five tiers have now bounced.
Item 1's remaining half. Oracle mechanized and reusable at tools/oracle/reg_renumber_swap.sh: break
at reload entry (cc1 unstripped: reg_renumber @0x82d4330, reload @0x815d4d7), swap two hard regs
across reg_renumber, finish the compile, re-score with masked_diff REUSED not reimplemented (R33).
NEGATIVE CONTROL: a no-op swap (31<->31) reproduces exactly the baseline 13 mismatches, so the
harness faithfully reproduces the pinned compile.
RESULT: both contested swaps are far WORSE — <-> (17 pseudos) = 345 mismatches +1 insn;
<-> (31 pseudos) = 97. Baseline 13.
WHY, AND IT REFUTES THE FRAMING: reading .greg for cluster B's own insn shows
(set (reg/v:SI 6 a2) (plus:SI (reg/v:SI 5 a1) (const_int 60)))
— the destination is a HARD register, not a pseudo. reg_renumber only maps pseudos (>=
FIRST_PSEUDO_REGISTER = 68), so that value is structurally unreachable by this oracle. The draft has
NO register __asm__ pins (header says so, grep confirms), so is hard because it is an incoming
PARAMETER register that local-alloc reused as a destination.
VERDICT for func_80176734 (51,198 ins): the residual is NOT global-allocation 2-colouring. It is the
LOCAL-alloc hard-reg reuse / tying class — combine_regs (2.7.2 local-alloc.c:1722) +
qty_phys_copy_sugg, i.e. regalloc.md K8/RC-4, whose lever is C-level LIFETIME SHAPING, not the
permuter and not reg_renumber. That also explains the flat permuter: it was mutating a dial that
does not control this residual.
MAP REFINEMENT OWED: §H presents the swap oracle as THE way to discriminate RC-6 from S3 in one gdb
run. It has an unstated PRECONDITION — the contested registers must be held by PSEUDOS. Check .greg
first; if they appear as (reg/v:SI N ...) with N < 68 they are already hard, and a coarse swap
returns a large meaningless number (345 here) that looks like a verdict and is not one.
Tree clean; nothing banked, nothing broken.
Probe-before-investing, ~15 min, settles the data axis.
FIRST: I recommended a RETIRED tool. tools/reconcile_decls.py is retired (Phase 26-A, R33, "DO NOT
RE-WIRE") and its docstring states the exact caveat I had raised independently — it asks what the
FLEET calls a symbol, while C asks what THIS TU declares; measured, the fleet oracle conflicts with
the TU's own declaration in 548/3431 (16%) of cases and hands back an actively wrong decl. Re-ran
with the live successor, reconcile_tu.py.
MEASUREMENT: reconcile_tu -> drafts 3, reconciled 3, 5 data symbols, 0 coverage defects.
Whole-binary gate (bare harvest_verify) -> verified 0 / failed 3, class DIFF=3. Tree residue 0.
WHY THIS IS NOT A NULL RESULT — THE FAILURE CLASS MOVED. Before: func_80133298/func_8012E014 were
PLUMBING; after reconciliation all three are DIFF. So reconcile_tu really did dissolve the
declaration conflict and the drafts still miss the bytes. func_80135260 is the witness: CC1-FAIL ->
compiles at 139 ins vs target 136, 123 mismatched. Conforming its data types to what the TU can see
CHANGED ITS CODEGEN. The drafts' data types are byte-load-bearing and the TU's declarations are
incompatible with them: the def-side loose-typing wall in DATA form, a genuine wall not paperwork.
Do not invest further in a data-axis conform for these three.
INSTRUMENT NOTE: my first probe used rtu_match, which reported CC1-FAIL "redefinition of s8" for
two drafts — a FALSE blocker, since rtu_match does not strip the scalar typedefs common.h provides
but harvest_verify does. The authoritative gate disagreed with my probe instrument and was right.
func_80135260 (18,768 ins) is re-filed: not an integration target, a CRACK target at 3 ins over.
I wrote 418 by wrongly excluding T32/T33 (the NEAR-6 wave + its 548-member sweep) as if they
belonged to SESSION-22; they ran this session. Caught by reconciling against the metric rather than
trusting the running tally: fn-count 319,549 -> 320,519 = +970, and the per-task recount agrees
exactly (4 + 548 + 4 + 143 + 133 + 1 + 137). Third counting slip today, and the third caught by
measuring instead of asserting — the reconciliation step is earning its keep.
T44 func_8013B83C: a MATCHING draft (272 ins) has been sitting unbanked in .run/s21_jt7/ since
Session-21 — found by measuring the preserved drafts against the right target (it is an _o0
function; my first probe used the wrong asm subdir). It does NOT bank: CARVE-REFUSED (has_mid_jr,
§53), and jtbl_carve then refuses because the _o0 subseg would host NON-CONTIGUOUS .rodata carves —
it needs jr_isolate_all (own code subseg, whale _o0b precedent) first. Tree verified clean; the
carve refused before writing. HONEST SIZING: the bank is 272 ins x1, and the 37,536 headline should
be DISCOUNTED — the exemplar is _o0 while its members are -O2, and today re-confirmed _o0 families
sweep ~1/137.
SESSION-23 FINAL CHECKPOINT written (supersedes the SESSION-22 blocks): 418 functions banked this
session, fleet 84.8->85.5% instr / 74.7->76.1% distinct / 90.34->90.61% fn-count, R22 140/140 run
7x, dedup 1886/0, 0 NON_MATCHING. Records the four strategic changes (every codegen-map file audited
vs real 2.7.2; the ADDRESSING->permuter route is wrong; the bare gate beats the ladder but has no
snapshot/restore; extract_unit's carry gap characterized), a ranked START-HERE list, my four errors
this session, and the carried defects.
The §99 conform_decls pass REFUSED this one (§85: 414 callers consume the return), so it was solved
from the DRAFT side. Three blockers, each measured:
1. §94 type-carry, and the draft's own header asserted something FALSE — it claimed both typedefs
already exist in engine_types.h. Measured: Hw4 1 hit, Prim4 1 hit, Env_800D29F8 ZERO. So in the
real TU the #ifndef guard is DEFINED and the typedef vanished -> "parse error before D_800AE7BC".
2. Signature axis: conformed the DRAFT to the fleet's declared `s32 *` return, then param 2
(s16 * -> Prim4 *). Byte-neutral because `src` is used EXACTLY once, as (s32)src. The error
("argument `src' doesn't match prototype") is again printed with NO "error:" prefix.
3. The family sweep went 0/137 TWICE before 137/137.
THE REUSABLE FINDING — a 0/N sweep whose exemplar banks cleanly is the signature of an extract_unit
carry gap. Measured on the staged member drafts:
file-scope extern -> CARRIED
file-scope #define -> CARRIED, but only while its expansion's deps stay file-scope
file-scope typedef -> NOT carried (silently dropped)
#define whose expansion references a BODY-LOCAL extern -> NOT carried
RECIPE: make the draft SELF-CONTAINED — body-local typedefs survive (PTag_80140D68 in this same
draft was the proof all along), and if that pushes a macro's dependency body-local, inline the macro
at its use sites. 0/137 -> 0/137 -> 137/137, 0 failed, each step byte-measured.
R22 clean-fleet 140 passed / 0 failed of 140; dedup-check 1886/0.
Fleet 85.5% instr, 76.1% distinct, 90.57 -> 90.61% fn-count.
§99 arc total (T41-T43): 133 + 1 + 137 = 271 functions. Both blockers Drew green-lit are CLOSED.
Drew green-lit the fleet-shared change. One function at a time from a committed-clean baseline, dry
run first, R22 after each step — the discipline the T39 shared-state hazard earned.
- conform_decls --fn func_80177DA8 --apply: byte-true def `void func_80177DA8(u8 *p, u32 v, s32 idx)`;
268 declaration sites rewritten across 268 files; the tool's own R32 completion assertion reports
"non-canonical declarations remaining: 0 OK (axis complete)" (§85 all-or-nothing as a COUNT, not a
hope). Nothing under src/shared, config or include. R22 -> 140/140: the decl axis is byte-neutral.
- Re-sweep: BANKED 133 / 0 failed, skipped {not-stub: 4} => the family went 4/137 -> 137/137, exactly
reversing T40's failure. R22 -> 140/140. dedup-check 1886/0.
- Fleet 85.4 -> 85.5% instr, 76.0 -> 76.1% distinct, 90.54 -> 90.57% fn-count.
T42 func_80140D68 — the pass correctly REFUSED it (414 callers consume the return, so widening the
return type is not byte-neutral, §85). Diagnosed in the real TU instead (rtu_match + reading ALL
stderr per §95 — gcc-2.7.2 prints hard errors with NO "error:" prefix, so grepping for "error" finds
nothing):
1. parse error before D_800AE7BC = a §94 TYPE-CARRY defect, and the draft's header asserts something
FALSE: it claims Hw4 AND Env_800D29F8 both already exist in engine_types.h. Measured: Hw4 1 hit,
Prim4 1 hit, Env_800D29F8 ZERO. FIXED by keeping Hw4 guarded (it does exist) and moving
Env_800D29F8 outside the guard, draft-local per §100. Still MATCH (65 ins).
2. conflicting types — conformed the DRAFT's return to the fleet's declared s32 * (still MATCH).
Only remaining delta: param 2 byte-true `s16 *` vs declared `Prim4 *`. conform_decls still refuses
(its return-axis precondition fires regardless). OPEN, with the next probe named.
family_sweep --hseq --band all --only <4 cores> -j12 -> 143 banked / 405 failed. R22 clean-fleet
140 passed, 0 failed of 140; dedup-check 1886/0. Fleet 85.3 -> 85.4% instr, 75.8 -> 76.0% distinct,
90.50 -> 90.54% fn-count.
Unlike T33's 548/548, this sweep mostly failed — so the failures were DIAGNOSED, not accepted:
- func_80138C60 swept 137/137 clean.
- func_8013B6A0 / func_8013B598 swept 1/137 each — EXPECTED, not a regression: Phase 20 byte-proved
the -O0 cluster is OVERLAY-LOCAL, so their siblings need per-overlay _o0 carves that do not exist.
- func_80177DA8 swept 4/137 — ROOT CAUSED: its banked def is K&R and its own TU declares it no-proto,
but NON-SC07 overlays declare a PROTOTYPE (extern void func_80177DA8(s32,s32,s32)), so the remap
conflicts. The 4 successes are SC07 overlays, which declare it not at all.
THE SYNTHESIS: that is the SAME §99 K&R-vs-prototype class as item 3's func_80140D68 (K&R def vs 138
prototype callers). ONE conform_decls pass unlocks both — ~17,000 instructions. conform_decls exists
for exactly this ("the draft's signature is byte-TRUTH; move the DECLS, never the draft"). NOT run:
it is a fleet-shared 138+-declaration change and this session already tripped one shared-state
hazard, so it wants an explicit go-ahead (P5).
MY ERROR, recorded: I read a `head -6` list of modified dirs as the complete set and briefly thought
the sweep's count did not reconcile. Measured properly it does — 143 stubs removed across 142 files.
Same class as grepping the wrong field earlier today: truncated output is not exhaustive output.
Worked Drew's order 1->2->3->4 at xHigh (no fan-out).
ITEM 1 func_80176734: permuter COMPLETELY FLAT at 13 (8 cycles x 240s, regalloc profile chosen over
the classifier's cse because the residual is 3 register 2-swaps). Not one improving waypoint in 32
min. THIRD ADDRESSING-bucketed target in a row where the permuter under-delivers (11->7, 10->6,
now 13->13 flat) — the T31 routing finding is now well evidenced. Remaining: the reg_renumber-swap
gdb oracle; feasibility confirmed (cc1 unstripped, reg_renumber @0x82d4330, prior-art .gdb exists)
but it needs a .greg pseudo-identification pass, so not started.
ITEM 2: 4 of 7 banked — func_80177DA8, func_8013B6A0, func_8013B598, func_80138C60. THE BARE GATE
WAS THE UNLOCK: gate_stage reported failed:2 on the _o0 pair while bare harvest_verify reported
verified 2/failed 0 on the SAME drafts, and rtu_match independently confirms func_8013B6A0 matches
in the real TU. That gives the carried "ladder-vs-bare-gate asymmetry" defect a REPRODUCTION — the
ladder is destroying good drafts, not diagnosing them. All 4 are reach-138 PURE families =
35,604 templatable instructions.
SHARED-STATE HAZARD hit and repaired: the failed func_80135260 attempt left fix_arity_callers
--any-proto edits in 17 TUs holding none of my banks (the bare gate has no snapshot/restore, unlike
the ladder after the Task-14 incident). Caught by diffing the tree, not by the tool's report.
Reverted the 17, kept the 3 bank-bearing files, re-verified R22 clean-fleet 140/140. Nothing under
src/shared, config or include was touched, so blast radius was ov_SC01_077-local (§63).
ITEM 3 func_80140D68: fails even bare-gated, and the PREDICTED CAUSE WAS WRONG — there is no
DEFINE_func_80140D68 macro. Real conflict is §99 K&R-vs-prototype: draft is K&R `u32 *`, 138 callers
declare `extern s32 *func_80140D68(s32 *, Prim4 *, s32, s32, s32);`. Lever exists (§99 did this at
1,072-decl scale today) but it is a fleet-shared 138-decl change. Scoped, not attempted.
ITEM 4 func_80178004 biv-init wall: RE-PROBED and UPHELD — my own hypothesis refuted. The cited
mechanism (loop.c:3803/3823, benefit->0 eliminates emit_iv_add_mult) is verbatim present in real
2.7.2 inside strength_reduce (3214); loop.md's flagged version difference is in combine_givs, which
this verdict does not rest on. The wall stands.
Derived the correct lines myself AND had an independent agent derive them separately — warranted
after two stacked line-number errors earlier in the session. Both derivations agreed exactly.
- expr.c:5535 -> 4577 (guard 4570-4576), case INDIRECT_REF: @4540, expand_expr @4026. 5535 is a
gcc-2.8.1 line; in our 2.7.2 it is MIN_EXPR/MAX_EXPR optab code.
- expr.c:5891 -> 4888, case COMPONENT_REF: @4748. THIS SECOND CITE WAS ALSO WRONG and had not been
noticed: 5891 lands in case COND_EXPR: (jumpifnot/cleanups).
Two precisions from the independent derivation, folded in rather than dropped:
- the INDIRECT_REF guard is a 4-WAY OR, not a single test (SAVE_EXPR-wrapping-PLUS, aggregate-typed
deref, and ADDR_EXPR-of-aggregate also grant /s), so "only when top-level PLUS_EXPR" was too
strong. The cast-defeats-/s rule is now bounded to a scalar-typed deref through a plain pointer —
which is the case the idiom is actually about.
- a SECOND MEM_IN_STRUCT_P (op0) = 1 at 4873 is conditional (BLKmode bitfield, returns early at
4876) and is NOT the one meant — flagged so it is not cited by mistake.
Old cites struck not deleted (H5); the top-of-file provenance note corrected (it named 4904, which
is the OFFSET_REF grant — a real third site but not this idiom's). Tool limitation recorded:
sweep_citations.py cannot tell a live cite from a struck-through historical one.
Docs-only: no src/ or config/ touched; R22 not re-run and not claimed.
T36 CORRECTION (the important half). Building the cookbook sweep tool surfaced a defect in
tools/verify_map_findings.py, which I had already used to validate BOTH map audits:
- GNU C sources use FORM FEED (\f) page separators — loop.c 47, cse.c 36, reload1.c 27,
local-alloc.c 21. Python's splitlines() splits on \f; grep/sed do not. Every line number computed
after the first \f was shifted (up to 47 in loop.c), which is LARGER than the checker's own +/-40
window — precisely how a real quote gets reported FABRICATED.
- Re-run after the fix: T34 regalloc 27 OK/153 NEAR/0 FAB -> 180 OK/0/0. T35 four-file
47 OK/240 NEAR/12 FAB -> 299 OK/0/0. THE AGENTS' LINE NUMBERS WERE EXACT ALL ALONG. I had even
written the false "off by +2..+19" claim into the T35 agent prompt.
- MY DIAGNOSIS OF THE 12 WAS ALSO WRONG. I said agents pasted map prose into source_quote and
"verified" it by grepping — but I grepped claim_excerpt (which IS map prose) instead of
source_quote. The real source_quote was ` record_jump_equiv (insn, 0);` at cse.c:7511, a
correctly-located C line. Two stacked errors: a broken tool, then a check of the wrong field that
appeared to confirm it.
- Fixed: both tools use split("\n"); verify_map_findings.py documents the trap so it cannot return;
loop.md's "12 unverified" note is WITHDRAWN in place. Nothing was deleted on this basis (all 12
were CONFIRMED-status, none underpinned a refutation), and the T34/T35 upheld/overturned splits are
unaffected — those came from adversarial agents, not the checker.
T37 THE COOKBOOK SWEEP (what was asked for). New tools/sweep_citations.py puts the mechanical half of
a citation audit into zero-token tooling (offline-tooling-first): symbol-form cites are compared to
the real 2.7.2 definition line; file-form cites are localised to their enclosing function.
- matching-cookbook.md: 57 resolvable citations, all localisable. MIXED provenance but mostly sound —
materially better than the map files. loop.c:5556, local-alloc.c:1765/1795/1825, global.c:906/917/
924/1000, local-alloc.c:1021/1064, global.c:588/594, sched.c:820, expmed.c:556, jump.c:2131 all
land where the prose says. GENUINE MISS: expr.c:5535 is MIN/MAX optab code; the /s grant sites are
4577 and 4904.
- STATED LIMITATION: "lands in the right function" is weak for giants (expand_expr 4026->~6300,
jump_optimize 139->~2200). This is a CITATION sweep, not a claim audit — proportionate because the
cookbook's idioms are byte-proven and its cites are explanation. No idiom re-litigated.
Docs+tools only: no src/ or config/ touched; R22 not re-run and not claimed.
Scope enumerated before acting: cse_expr.md, loop.md, sched.md (full pass — T33 landed only a
partial), t7g-giant-harvest.md. 35 agents (9 derive + 26 adversarial refute), 2.48M subagent tokens.
308 findings: 174 CONFIRMED / 99 LINE-DRIFT / 26 REFUTED raised -> 20 UPHELD, 6 OVERTURNED / 9
unverifiable. cse_expr.md had the highest error density (17 refuted of 74); loop.md the lowest (3 of
96) thanks to its pre-existing caveat table.
12 FABRICATED (vs 0 last audit) — DIAGNOSED, not waved through: the agents pasted MAP text into the
source_quote field instead of compiler source. All 12 are CONFIRMED-status and none underpins an
upheld refutation, so nothing was deleted on bad evidence — but they are UNVERIFIED, they sit in
loop.md's biv-elimination area, and loop.md now records that as an open gap rather than a pass (R32).
Headline corrections:
- cse_expr: THE 1000-INSN CSE FLUSH DOES NOT EXIST IN 2.7.2 (added in 2.8.1; grep num_insns -> no
hits). It drove THREE places — §1's killer table, §6's giant tell, §7's "shift +-insns across the
1000 boundary" lever. A lever aimed at a counter our compiler lacks, in exactly the giants this map
serves. All struck.
- cse_expr: §2's "kill THE class reg" is singular and wrong. The audit BYTE-REPRODUCED T31's wall on
the pinned cc1: expand_block_move (mips.c:2350-2351) copy_addr_to_reg's BOTH aggregate addresses.
Two byte-proven remedies recorded, with the caveat that field-by-field copy is closed when the
target's own bytes need the block move (func_80132F40's case).
- cse_expr: assign_temp absent in 2.7.2 and no /s reset on slot reuse (recycled slots INHERIT /s);
no BUILT_IN_MEMSET; §6's "recompute after a join is never a residual" false at -O2.
- sched: S7's EPILOGUE half false (no live define_expand "epilogue" on MIPS) — re-scoped not deleted;
insn_cost is DEP-KIND-BLIND so restoring /s anti edges is not free.
- loop: "no memory load is EVER hoisted from a loop containing a call" FALSE — invariant_p checks
RTX_UNCHANGING_P first; byte-proven that a const int* load hoists to the preheader. Call args are
emitted LEFT-to-right, not right-to-left.
Remaining: matching-cookbook.md (~52 citations, MIXED provenance) — but a DIFFERENT risk profile,
since its idioms are byte-proven and citations are explanation, so a targeted citation sweep is
proportionate rather than a full audit. Not done; flagged.
Docs-only: no src/ or config/ touched, R22 not re-run and not claimed.
26 agents (5 derive + 21 adversarial refute), 1.73M subagent tokens. Two guards, because a false
REFUTED deletes a working lever and is worse than a stale line number:
- MECHANICAL FABRICATION CHECK (.run/verify_regalloc_findings.py, NEW): every claim had to carry a
verbatim source_quote + file + line; I re-opened each file at each line and compared. 184 checked,
**0 FABRICATED** (27 exact, 153 NEAR = quote real but line arithmetic off by +2..+19, 4 declared
unverifiable). Distinguishes NEAR from FABRICATED because the 2.8.1->2.7.2 drift (+300..+600 in
reload1.c) can land a lookup inside a DIFFERENT function and still read plausibly.
- ADVERSARIAL SECOND STAGE: every REFUTED claim went to an independent agent told to refute the
refutation, defaulting to upholding the map. **Of 21 REFUTED, 14 OVERTURNED, 7 stand.** The raw
audit output would have deleted 14 CORRECT levers (RC-6's verdict, the decoy-qty lever, the
<=3-qty creation-order rule, the keepalive-read lever).
FINAL: 119 CONFIRMED / 40 LINE-DRIFT / 7 REFUTED-upheld / 4 UNVERIFIABLE. The model is sound.
The 7, marked [A23] inline:
1. K4 flag_caller_saves is ON (toplev.c:3387-3394 at -O2), BYTE-PROVEN on the real cc1 — a
call-crossing value is not confined to $s0-$s7-or-spill. Added the missing diagnostic:
caller-save slots are 4-BYTE-PACKED vs reload spill slots 8-ROUNDED (misreading one as the other
sends you to RC-1 + decl reordering, the wrong lever entirely).
2. RC-7's premise false: a frame address is never CONSTANT_P (rtl.h:237-240 excludes PLUS), so it
gets a real slot + lw. THIS EXPLAINS T31's byte-tested failure today — cse_expr.md §2's remat
recipe could not dissolve func_80132F40's hoist (47->40, never 0) because the promised mechanism
does not apply to frame addresses. Independent audit and live byte-test converged.
3. The "init MOVED to just before its use" pass is 2.8.1-only; 2.7.2 deletes the init instead.
4. K2 refs are LOOP-DEPTH-WEIGHTED (reg_n_refs += loop_depth), not per-insn-mention.
5. K1 qty numbers come from BIRTH order, not regno order.
6. RC-15/K2: allocno_live_length is the DENOMINATOR — priority is a density.
7. Pins do NOT kill the S2 boost — independently reproducing yesterday's sched.md finding from a
different agent/section, plus the decisive detail that sched.c:423 DOES add the pseudo guard
where it wants one, so the omission at :2478 is deliberate.
NOT applied: the 40 LINE-DRIFT fixes wholesale — generic quotes match several places, so publishing
all 40 risks replacing 2.8.1 drift with fresh 2.7.2 drift. Header carries 12 hand-verified anchors +
an instruction to grep before citing. Struck text preserved, not deleted (H5).
Docs-only: no src/ or config/ touched, R22 not re-run and not claimed.
- family_sweep --hseq --band all --only <4 cores> -j12 -> BANKED 548 member-matches / 0 failed
across 137 overlays. Preconditions CHECKED not assumed: map regenerated first (sig-overlays +
family_hseq) so the exemplars read matched-ov077 not the stale draft-ov077; all 4 families
has_mid_jr=false (§53 carve law) and diff_class PURE 137/137; --band all because two cores are
`mid` and the default `substantial` band would have silently dropped them; --reconcile-raw avoided.
- R22 clean-fleet after the sweep: 140 passed, 0 failed of 140. dedup-check 1886 validated / 0
failed, C1 coverage 239604/239604, 0 NON_MATCHING in any default build (G4).
- SESSION ARC: instr 84.8 -> 85.3%, distinct-code 74.7 -> 75.8%, fn-count 90.34 -> 90.50%.
552 functions banked (4 exemplars + 548 members) ~= 74,802 templated instructions.
- sched.md SOURCE-VERSION CORRECTION: the map declares its source as gcc-papermario, which Phase 23
established is gcc 2.8.1 — not our 2.7.2 — and it was never re-derived. Citations are correct for
the WRONG compiler. One claim is byte-refuted and load-bearing: §1.7/§S12 said the S2 birthing
boost needs SET(REG_pseudo,...) so pins must be removed ("Unpin first"); real 2.7.2
birthing_insn_p (sched.c:2469) tests only GET_CODE(SET_DEST)==REG with NO pseudo check and gates on
reg_n_sets==1 (2490) — hard-reg dests ARE boosted. Corrected in place (old text struck, not
deleted) + a hand-verified 2.7.2 cross-reference table and a warning block.
DRIFT IS NOT UNIFORM: ~+27 in sched.c but +103/+377/+611 in local-alloc.c/reload1.c — big enough to
land inside a different function. ~44 drifted citations across sched/regalloc/loop .md (a screen,
a lower bound). regalloc.md is worst and is NOT yet re-derived — named as next.
- All line numbers verified by me against tools/reference/gcc-2.7.2, not taken from the agents.
Ultracode fan-out (12 agents, 1.70M subagent tokens): 6 crack agents, one per NEAR target, each
carrying its byte-measured residual + T31's disproved routes, then a distill agent per target that
adversarially re-checks the claim.
- BANKED ×1 (whole-binary gate, gate_stage --no-propagate per §55b law 1): func_80140958 (260 ins),
func_80177B5C (147), func_80132F40 (72), func_8012E364 (67). Every agent MATCH claim was
RE-MEASURED BY ME with match_one before it was believed (G3/P9: match_one is a candidate, a bank
is the whole-binary gate), and verified against the SOURCE not gate_stage's accumulating
verified-list (§55b trap 4). R22 clean-fleet: 140 passed, 0 failed of 140.
- engine_core.h moved by exactly one byte-neutral arity fix (void -> no-proto) = fleet-shared, so
R22 was mandatory (§61/§63), not the per-binary gate.
- func_80140D68 MATCHes standalone but NOT whole-binary — the §30a integration class; its distill
agent named the likely cause in advance (DEFINE_func_* extern must return u32*, not void).
- func_80176734 217 -> 13 with the instruction count now EXACT (371/371). cse_expr.md §H's "no bank,
5 permuter-shaped clusters" is BYTE-REFUTED: 4 of 5 were steerable from C; the -1 length delta was
a combine/LOG_LINK effect (flow.c links a SET only to the next use in the SAME bb), not frame
pressure. Two coupled allocator/sched ties survive.
- FOUND: docs/gcc-2.7.2-map/sched.md cites gcc-2.8.1 line numbers (birthing_insn_p 2498->2469,
adjust_priority 2534->2507, potential_hazard 1345->1318, schedule_select 2646->2616) — surviving
papermario numbers Phase 23's source-version correction never swept. One is LOAD-BEARING: §1.7 and
§S12 claim the S2 boost needs SET(REG_pseudo,...) so pins must be removed; sched.c:2477 tests only
GET_CODE(SET_DEST)==REG with NO pseudo check, discriminator is reg_n_sets==1 (2490). Verified by me
against tools/reference/gcc-2.7.2, not taken from the agents. Map edits owed (next task).
- MY DEFECT: all 6 agents shared one scratch dir (1,452 files); deliverables are uniquely named and
verified intact, but short-named scratch could collide. Per-agent subdirs next wave.
NOTHING BANKED — no draft reached closeness 0. Recorded as such (P9). No src/ or config/ change,
so the fleet is untouched at HEAD's verified 140/140; R22 deliberately NOT re-run and NOT claimed.
- VERIFIED the checkpoint's six closeness numbers against the bytes (R14/R35): 217/10/11/6/7/9 all
reproduce EXACTLY through match_one --json, with asm_subdir/-O0 DERIVED from wave22_targets.json
rather than guessed. All six are reach-138 cores = ~135,516 templated ins (~1.04pp) if cracked.
Reproducer .run/near6_measure.py.
- PERMUTER (only 2 of 6 are §60a-admissible): func_80177B5C 11->7, func_80140958 10->6, both
re-measured with match_one — an oracle INDEPENDENT of the permuter's scorer (R34) — agreeing
exactly. Both plateaued after cycle 1. Seeds preserved + allowlisted.
- THE FINDING: residual_class routes ADDRESSING -> permuter, but gcc-2.7.2-map/cse_expr.md §2
documents that exact class (hoist-vs-remat) as STEERABLE by a byte-proven C recipe. The tool
spends CPU searching for what the map says has a deterministic fix, and both ADDRESSING targets
plateaued exactly as that predicts. R35-shaped instrument defect, not a compiler wall.
- NEGATIVE RESULT, byte-tested on func_80132F40 (6 variants): the §83d CSE fork is REAL (s32 fixes
the min-block opcodes but hoists &v[0] into a 5th callee-saved reg, 47 mism), and the §2 kill
moves it (47->40) but does NOT dissolve it in 3 placements. §2 has an unstated boundary: proven
where the address's only uses are call arguments; a STRUCT-COPY source address survives the kill.
close=6 (s16) remains the best known state — the wave agent's verdict, independently re-earned.
- NEW DIAGNOSIS: func_80140958's post-permuter residual is not scheduling — my draft CONSTANT-FOLDED
a loop value the target keeps live (li v0,3 / li a3,3 / li t3,12 vs addu/sll from $v1). Untried.
- NOT SPENT, deliberately: func_80176734 (already a no-bank Fable5 pass, §H), func_80140D68 (~200
compiles already), func_8012E364 (~2500 variants already).
- tools-health exit 0 (green, fail-closed) at preflight.
Its 0/137 was the §94 TYPE-CARRY signature: the draft defines `typedef struct {…} Sp_80175DA8;` at
FILE scope, and remap_hseq templates the BODY but not the type, so every sibling compiled without it.
§94's remedy is the shared engine_types.h lift (right for func_8016B6BC, whose four types were
transitively referenced). But the cheap remedy was already in the same draft: it carries S_AF634 at
BLOCK scope and that templates fine, because a type declared in the body travels WITH the body.
Sp_80175DA8 is used by that function ONLY (7 mentions, 6 inside the body, 0 elsewhere), so moving it
into the body is byte-neutral (d19c9580 unchanged), T0, zero blast radius — versus editing a header
included by 140 binaries with uniquify/collision care and an R22.
Re-swept: 137/137, 0 failed. R22 clean-fleet 140 passed / 0 failed of 140.
MEASURED: fn-count 318,720 -> 318,857 (+137); instr 84.2 -> 84.4% (+31,647 ins); distinct-code
73.9 -> 74.4% (+129 unique fns).
§99 AND §100, AN HOUR APART, ARE THE SAME LESSON: both times the cookbook's named remedy was the
expensive fleet-wide one (524-site decl conform / shared-header lift) and the correct fix was
DRAFT-LOCAL (K&R definition / block-scope typedef). Before editing anything shared, ask what the
smallest scope is that still travels with the body.
The first sweep returned "banked 0 / skipped {'pinned-exemplar': 137}" — a SKIP, not a failure. The
§42e guard refuses pinned exemplars to avoid a cc1 SIGABRT, but Phase 27 BYTE-PROVED that crash was
extract_unit dropping file-scope macros (a TOOL bug, fixed by _carry_macros), not a compiler limit.
Re-run with --allow-pins: 133/137 BANKED. R22 clean-fleet 140 passed / 0 failed of 140.
MEASURED: fn-count 318,585 -> 318,720 (+135); instr 84.0 -> 84.2% (+25,423 ins); distinct-code
73.4 -> 73.9% (+127 unique fns).
THE GUARD IS NOW COSTING BANKS — the same shape as sweep_parallel being opt-in: a protection that was
correct when written, whose cause was later removed, still defaults ON. Measured cost on ONE family:
137 skipped, 133 bank fine. Phase 27's roadmap delta already said the PINS class was back on the
table; nothing changed the default. Flipping it is a one-line change, deliberately deferred to a
fresh session — that is exactly how family_sweep got broken twice today.
SC07 QUARTET, third occurrence today, now named: ov_SC07_006/007/010/011 refused again (same four as
func_80176218). NOT broken — func_8014CF04, func_8015D1B8 and func_801789AC all swept them cleanly.
The correlation is the sibling TU (_jr_8016AE5C.c, a different carve layout; these 4 were onboarded
in Phase 27 with code at PAC entry 1). §59: read ONE sibling's real gate result before concluding.
func_80175DA8 0/137 is the §94 TYPE-CARRY signature (local typedef Sp_80175DA8 templated as a body
but not as a type) — the same shape that took func_8016B6BC 0/137 -> 137/137 today. Named next step,
31,878 templated instructions.
func_80175AB8 + func_80175DA8 both banked. R22 clean-fleet 140 passed / 0 failed of 140.
§92 SAID these need "the §17a-1 caller pair, NOT a bare conform" — the diagnosis was right (conforming
a narrow param changes argument promotion at every call site, measured PLUMBING -> DIFF) but the
remedy was the expensive one. The actual fix touches NO declaration: convert the DEFINITION to K&R,
where a narrow param PROMOTES to int (C89 6.3.2.2) and is therefore already compatible with the
fleet's existing `s32` prototype, while still emitting narrow-param codegen. §43 applied to the def
side. T0 draft-only, ZERO blast radius, versus a 524-site fleet conform.
THREE reconcile_tu BUGS SURFACED, ONE OF THEM MINE:
(a) BLIND TO BLOCK SCOPE. split_statements is depth-0 BY DESIGN, and §8d deliberately demotes data
externs into the function body — so the tool saw one statement and no declarations, printing
"reconciled: 0 draft(s), 0 data symbol(s); coverage defects: 0" for a draft cc1 rejected with
`conflicting types for D_8011F7BC`. A silent skip (R32). Fixed: descend one level.
(b) MY BUG, introduced by (a): descending into ANY `{` also enters struct/union/enum definitions, so
MEMBERS parse as declarations and get conformed — `u32 code;` became the TU's
`typedef void (*code)(unsigned short*);` INSIDE the struct, and `p->code` became
`p->(*(u32 *)&code)`. Caught by DIFFING THE TOOL'S OUTPUT AGAINST ITS INPUT before trusting it;
the byte-gate would have said PLUMBING and explained nothing. Guard: function bodies only.
(c) LATENT since the tool was written: _cast_sub matched bare identifiers and rewrote MEMBER ACCESSES
as globals. Unreachable until (a) existed. Guard: (?<![.\w])(?<!->).
cookbook §99.
137/137 banked, 0 failed via jtbl_family_bank. R22 clean-fleet 140 passed / 0 failed of 140; report
fail-closed green (dedup 1886/0, C1 coverage 239604/239604, 0 NON_MATCHING).
MEASURED: fn-count 318,447 -> 318,585 (+138); instr-weighted 83.9 -> 84.0% (+12,558 ins);
distinct-code 73.2 -> 73.4% (+131 unique fns — byte-VARIANT members, so unlike func_801330E0's
byte-identical family this one moves the distinct number too).
Closes the function REFUSED since SESSION-21 — correctly refused, since conforming its 660
declarations without first casting its 138 zero-arg call sites would have broken 138 binaries.
Also logged (T21): the sweep-throughput measurement. Drew was right that parallelism was proven and
adopted (Makefile JOBS=16; sweep_parallel.py -j12 built SESSION-20 after measuring an 8-16x loss),
but NEITHER sweep tool calls it — the adapter is reachable only via a manual --stage-only two-step,
so three sweeps today ran serially for no reason. The -j theory was wrong and measurement said so:
make is ~5s of the 16s per sibling (the loop runs up to FOUR builds per sibling), so -j16 is a 12%
win, kept but minor. The real 8-16x lever is blocked on revert() restoring the SHARED
config/overlays.mk from git — designed, not built. An attempt to wire family_sweep's parallel default
broke it twice and was reverted rather than committed.
137/137 banked, 0 failed. R22 clean-fleet 140 passed / 0 failed of 140.
MEASURED: fn-count 318,309 -> 318,447 (+138), crossing 90.03%; instr-weighted 83.8 -> 83.9%
(+15,180 ins); distinct-code +1 unique fn.
AN HONEST NUANCE: distinct-code moved only +1 here vs +126 for func_80176218's family, because these
137 members are byte-IDENTICAL (h_exact) and collapse to one distinct function, while func_80176218's
were genuine byte-VARIANTS. Both are real work; they move different metrics. The 3-metric dashboard
exists so one number cannot flatter the other.
This family banked only because conform_decls learned to read K&R definitions an hour ago: one tool
gap, unblocked, became 138 functions.
SESSION-22 TOTAL: 6 exemplars + 680 members = 686 functions.
The largest single family on the census: 137 siblings x 289 ins. Per sibling — jtbl_carve -> make
extract -> remap_hseq + canon_sig_reconcile -> whole-binary gate, revert-on-fail. 137/137 BANKED,
0 failed. R22 clean-fleet 140 passed / 0 failed of 140; report fail-closed green (dedup 1886/0,
C1 coverage 239604/239604, 0 NON_MATCHING).
MEASURED: fn-count 318,171 -> 318,309 (+138); instr-weighted 83.4 -> 83.8% (+39,882 ins);
distinct-code 72.5 -> 73.2% (+131 unique fns).
TWO TOOL REFUSALS MADE THIS BANK POSSIBLE, and both deserve recording:
- family_sweep REFUSED the family (has_mid_jr): §53's carve law says a carve-less sweep there returns
"a 0% that is a TOOL artifact, not a wall". Overriding with --allow-jr would have yielded 0/137 and
plausibly filed the highest-value family on the board as a wall.
- jtbl_family_bank REFUSED a dirty tree: its per-sibling revert restores from HEAD, so the
uncommitted 414-file decl axis would have been destroyed. H4 enforced in code.
This is the inverse of the session's earlier failures, which all came from tools that ANSWERED
instead of refusing.
SESSION-22 TOTAL: 5 exemplars + 543 members = 548 functions.
Fleet: 82.9 -> 83.8% instr, 71.5 -> 73.2% distinct-code.
BANKED 273 member-matches / 0 failed across 137 overlays (func_8014CF04 136 + func_8015D1B8 137).
R22 clean-fleet 140 passed / 0 failed of 140; report fail-closed green (dedup 1886/0, C1 coverage
239604/239604, 0 NON_MATCHING).
MEASURED from the committed digests, not projected: fn-count 317,898 -> 318,171 (+273);
instr-weighted 83.2 -> 83.4% (+26,770 ins); distinct-code 72.3 -> 72.5% (+129 unique fns).
A USEFUL NEGATIVE RESULT: both families swept cleanly across ov_SC07_006/007/010/011 — the same four
overlays that refused func_80176218's sweep earlier today. So that set is not broken; the 4/137
refusal is family-specific (the _jr_8016AE5C.c carve), which is the per-sibling INTEGRATION signal
§59 describes rather than a codegen or overlay-level wall. Carried, still not concluded.
SESSION-22 total: 3 exemplars + 406 members = 409 functions.
THE BANK: the T14 PLUMBING census showed func_8014CF04 blocking THREE drafts at once. Conforming its
decl axis banked func_8014CF04 + func_8015D1B8 (func_80135260 is a genuine DIFF, agreeing with its
independent SESSION-21 diagnosis). R22 clean-fleet 140/140; report fail-closed green (dedup 1886/0,
0 NON_MATCHING). fn-count 317,896 -> 317,898; distinct 66,110 -> 66,111.
BUT THE AXIS WAS A 1,748-FILE T2 WRITE SET (the --check per-form counts read "1"), and R22 came back
139/140 -- TWICE -- on a change the per-binary gate called BYTE-IDENTICAL. Three defects (§98):
1. THE REGEX CROSSED NEWLINES. `[^;]*` matches '\n', so a match starting at a DEFINITION line ran
past the `{` to the first `;`, swallowing `s32 func_8014CF04(...) {` PLUS the register pin on the
next line and replacing both with a prototype -> undefined reference. Fixed to `[^;{\n]*`: a
definition is now unmatchable by construction.
2. IT REWROTE INSIDE COMMENTS (H5, 3 lines). Now scans cdecl._mask() and rewrites by SPAN (R33 --
that length-preserving primitive already existed for exactly this).
3. THE REAL CAUSE -- IT ASSUMED ONE SIGNATURE FITS THE FLEET. ov_SC07_006 carries its own banked
definition with a DIFFERENT byte-true signature ((s32,s32,void*) vs (s32,void*,void*)), under a
decl marked "per-overlay-local decl (byte-true sig); do NOT re-macroize". That is the Phase-16
loose-typing wall inside a tool that structurally assumes it away. NEW RULE: a TU that DEFINES the
function owns its own declarations; a fleet axis is meaningful only for CONSUMING TUs. This grows
more common as banking proceeds -- every overlay that banks a function becomes an exception.
Then the R32 completion assertion cried wolf on its own by-design skip ("HALF-AXIS -- DO NOT BUILD"
for a complete rewrite): an assertion must be exact about its DOMAIN, not just its condition. Scoped
to consuming TUs -> 1,747 sites, 1 excluded by design. Also hardened to PLAN -> VALIDATE -> WRITE;
the refusal path had aborted mid-write while claiming nothing was modified, creating the very
half-axis §85 calls a guaranteed break.
META (R22's premise, re-earned): after fixing defect 1 I EXPECTED R22 to pass; it failed again for an
unrelated reason, and an individual `make build` of the failing binary SUCCEEDED by reusing objects
the clean run rebuilds. An incremental pass does not refute a clean-tree failure.
A 15-draft harvest_verify batch reported CC1-FAIL=4 and `final SHA None`. Three of the four were the
HARNESS, not the compiler. Checked the tree FIRST (the MISMATCH is a tree alarm, not a result),
reverted to the committed baseline rather than reasoning about a half-applied state, rebuilt ->
d19c9580 BYTE-IDENTICAL. No banked result was ever at risk: the byte-gate cannot manufacture a match,
but it CAN manufacture a verdict — and verdicts are what the backlog and roadmap are built from.
ORDERING PROVED THE CASCADE (R14): items 1-11 are real (9 PLUMBING, 2 DIFF), all before item 12 —
jtbl_carve REFUSING func_8013B83C (§59(3) non-contiguous same-subseg table). Items 13-16 are four
CC1-FAILs on the SAME ov_SC01_077_o0.o = one refused carve counted four times.
THREE DEFECTS FIXED:
1. `_ok` was computed and IGNORED — a refused carve was spliced and built anyway into a guaranteed
Error 33, filed as CC1-FAIL. Now a named CARVE-REFUSED class, skipped (one build cheaper).
2. attempt() never restored on failure, so the tree was dirty BETWEEN drafts — and _jtbl_snapshot()
snapshots the tree AS IT FINDS IT, so a later carve captured an earlier FAILED draft's splice and
its undo faithfully RE-APPLIED it, after the final _write(baseline). That is the entire
`final SHA None` mechanism. Invariant restored: the tree is at baseline except while a draft is
under test (atomic AND bisect branches).
3. The recovery's own `make extract` rc was unchecked (_sh does not raise — §93's sibling). Now loud.
Plus an R32 assertion on the cleanup: at 0 verified a non-empty git status is residue, not a result;
it names the files and the recovery command. It fired correctly on its first real run.
MEASURED RECOVERY (same drafts, clean tree): func_8013B83C -> CARVE-REFUSED; func_801789AC ->
PLUMBING (actionable); func_8017C974 -> DIFF (corroborates its agent's global_alloc spill diagnosis);
func_80140958 -> CC1-FAIL (genuinely its own). final SHA None -> d19c9580; tracked diff empty.
BLAST RADIUS OF §96, HONESTLY: the reconcile_tu span fix unblocked func_80176218 (banked, swept
133/137) and no other draft in the batch. 7 of the 9 PLUMBING are `conflicting types for <the
function itself>` = the DEF-side self-decl axis conform_decls owns — the next lever, now a measured
target list rather than a guess. cookbook §97.
+134 functions banked total for this exemplar (1 + 133 members). Measured from the committed
progress.fleet.md, not projected: fn-count 317,762 -> 317,896; instr-weighted 82.9 -> 83.2%
(+43,818 ins); distinct-code 71.5 -> 72.3% (+126 unique fns — these members are genuine byte-
VARIANTS that each count distinctly, not free dedup).
VERIFY: R22 clean-fleet (make clean && extract-all && check-all) -> 140 passed, 0 failed of 140.
make report fail-closed green: dedup-check 1886 validated / 0 failed, C1 coverage 239604/239604,
0 NON_MATCHING in any default build (G4).
THE 4 FAILURES ARE CARRIED, NOT CONCLUDED. All four are ov_SC07_006/007/010/011 and all four differ
from the other 133 in exactly one way: their sibling TU is _jr_8016AE5C.c, not _jr_801734BC.c —
carved under func_8016AE5C, which was banked and swept in SESSION-21. That is the SAME four overlays
and the SAME carve the SESSION-21 checkpoint flagged as "worth checking first" for func_8016B6BC's
0/137, which turned out to be a transitive type-carry (§94) rather than a wall. Each sibling reverted
its byte-neutral self-decl edit cleanly, so no dead diff is left behind. Per §59 a sweep failure is a
per-sibling INTEGRATION signal, not a codegen verdict — read one sibling's real gate result
(COMPILE-fail vs byte-DIFF) before concluding.
THE DRAFT was failing in a CHAIN, one "next conflict" per gate cycle. Applied §95's own diagnostic
law instead — splice once, dump EVERY cc1 error — and the whole set named the cause immediately:
three errors on TWO axes (one data decl, two callee decls), not three problems.
THE DATA ERROR WAS reconcile_tu AGAIN, ONE SHAPE DOWN (§96). split_statements returns comment-
STRIPPED text WITH SPANS; the rewrite re-found each planned statement by comparing that text to a raw
LINE, so `extern u8 D_80078E78; /* cur base ($s5) */` never matched. The decl was left unconformed
WHILE THE USE-CAST PASS STILL FIRED -> a draft whose uses are cast for the TU's storage against the
draft's own declaration -> cc1 reports `conflicting types` AT THE VERY DECL THE TOOL JUST CLAIMED TO
FIX, exit 0, "reconciled: 3 symbols".
FIX: rewrite by SPAN (the primitive existed — its docstring says spans are preserved *because drafts
get rewritten*). Plus the R32 assertion the old code was missing: it had a dropped_check counter
incremented in two places and NEVER COMPARED — "a loud failure nobody counts is exactly as invisible
as a silent one" in miniature. Now declarators-in vs -out AND a per-symbol check that each planned
tu.declaration() actually landed, both as `!!` notes so --strict exits non-zero.
MEASURED: 3 -> 4 data symbols reconciled on the same draft; trailing comments preserved (H5).
THE TWO CALLEE CONFLICTS were the other axis (reconcile_tu skips kind=='func' by construction):
cast_call_sites (§20) conformed func_80177AD4 (TU `void (int, unsigned int)`) and func_80178298
(TU `(u32*, u8*, short, short)`) and cast each call site to the draft's intended widths.
GATE: verified 1 / failed 0, d19c9580 BYTE-IDENTICAL. Write set is one overlay-local TU = T1 per the
§63/§85 blast-radius taxonomy, so the per-binary gate is sufficient; the ×137 sweep is the T2 case
and takes a full R22.
CHECKPOINT HYGIENE: between T11 and T12, wave 2 + a bank + a new tool guard were recorded ONLY in
commit messages — CURRENT_PHASE.md and the cookbook were stale for that stretch. The quiet periods
were background sweeps/R22 (~2h each) during which the tree cannot be touched, but that does not
excuse leaving the durable record behind: a stale checkpoint is worse than an absent one. Closed.
cookbook §92 — conforming a DECLARATION: pointer changes are caller-neutral, scalar-WIDTH changes
are NOT. Byte-proven both ways (func_80179B74: 1,600 sites / 523 files / 3 forms, banked, R22
140/140; func_80175DA8: PLUMBING before the conform, DIFF after — the conform did not fix the draft,
it changed the callers). Plus the arity case that broke 138/140, and the counting lesson:
func_8015B950 looked like ~926 call-site casts and needed ONE — its only 0-arg call sits in an
engine_core.h DEFINE macro the preprocessor expands 926 times. Count SITES, not expansions.
cookbook §93 — `set -o pipefail` attributes a pipeline failure to the LAST stage, not the failing
one: cc1 exit 33 reads as an assembler error because `as` ends the recipe. The 2-minute fix is to run
the stages by hand printing each rc, then re-run the failing one with stderr visible. Turned an
opaque Error 33 into a one-line fix twice today. Corollary (§88e, earned): hand a stuck function over
as an UNDIAGNOSED observation, never as a named cause — flagged that way, the agent found the true
cause (cc1 `conflicting types for 'Ent'`) immediately.
func_8014D820 family swept 137/137. func_8016B6BC 0/137 reproducibly — recorded as a DIAGNOSIS task
per §59 (a sweep 0/N is a per-sibling integration signal, not a codegen verdict), never as a wall.
Checkpoint fn-count corrected 89.88 -> 89.80 against the measured report; stray a.out removed (R12).
BANKED: func_8015B950 (271 ins) · func_8016AE5C (85) · func_80179B74 (111).
SWEPT: func_8015B950 137/137 · func_8016AE5C 136/137 (ov_SC03_108 refused, left a stub rather than
forced). Three full family sweeps this session, all unblocked by the --like role guard.
FLEET 82.4% instr · 70.4% distinct-code (crossed 70%) · 89.72% fn-count. R22 140/140 throughout.
conform_decls has now been right in BOTH directions: it REFUSED func_8015B950 (which by hand broke
138 binaries) and CLEARED func_80179B74 (1,600 sites / 523 files, three decl forms, pointer-type
only). Then it found its OWN coverage gap: it required a leading `extern`, so it reported "no
declaration found" for a TU declaring the function on line 23 without one — a silent miss that reads
exactly like "nothing to do" (R32). `extern` is now optional and PRESERVED where present.
⚠️ INSTRUMENT FAILURE, recorded: mid-session `grep <pat> <file> | head` began printing NOTHING while
exiting rc=0 (i.e. matching). Read showed the line plainly; re-done in Python the file has 3
occurrences including a CALL at line 68. It cost one wrong intermediate claim ("no extern anywhere"),
which conform_decls immediately contradicted. NO banked result is affected — every bank passed the
whole-binary byte-gate and a clean-tree R22, neither of which reads shell output. A broken diagnostic
wastes time; it cannot manufacture a match. Diagnostics moved to Python. §90a, aimed at the shell.
func_8013BD74 is NOT a wall: its byte-true def takes a draft-LOCAL struct `A`, conforming the
prototype fails `parse error before '*'` (A undeclared that early), and the prototype cannot be
deleted because a call at line 68 precedes the definition at 71. Needs the §20/§64 type-lift.
BANKED: func_8016AE5C (85 ins ×138). R22 clean-fleet 140/140.
⚠️ I BROKE 138 OF 140 BINARIES AND R22 CAUGHT IT — the per-binary gate could not.
Conforming func_8015B950's decl from `(void)` to its byte-true `(s32 arg0)` across 926 sites gated
BYTE-IDENTICAL on ov_SC01_077 and broke 138 other binaries with Error 33. §63/§85 exactly: a T2
write set is provable only by R22, and the binary the gate authorises is not the binary that breaks.
MECHANISM: conforming a decl to a signature that TAKES parameters makes every existing 0-ARG CALL
SITE a hard `too few arguments` error once a prototype is in scope. Not a declaration-only change.
PROCESS NOTE (mine): a first R22 reported 138 failures, an individual rebuild of a "failing" binary
said BYTE-IDENTICAL, and I nearly filed it as a flake. The second clean R22 reproduced it exactly —
the individual build passed only by reusing objects the clean run rebuilds. An incremental pass does
not refute a clean-tree failure; that is R22's whole premise, pointed at me. Reverted to a known-good
baseline (a stray jr_isolate region file was also in the tree) and redid the one good bank cleanly.
NEW tools/conform_decls.py — because applying this axis by hand three times in one session is how a
half-axis happens. Derives the byte-true signature from the DRAFT's definition (§58b), rewrites EVERY
site, asserts completion (R32). Encodes both preconditions: the §85 return axis (refuse if any caller
consumes the return) and a NEW arity precondition (refuse if 0-arg call sites exist, naming the cost).
The guard immediately gave a better diagnosis than my hand-fix had: func_8015B950's 0-arg call is in
ONE place — src/shared/engine_core.h, a DEFINE macro body — expanded into all 926 TUs. That fix is a
SINGLE cast, not 926 edits. Named as the next step rather than run on tired context.
Also lands cookbook §91 (the --like role trap) from the previous step.
- family_sweep --hseq over the 3 newly-banked exemplars: BANKED 274 member-matches / 137 failed
across 137 overlays, for ~0 agent tokens. Session total: 3 exemplars + 274 members = 277 fns.
- THE STALE-MAP STEP, hit and handled: the first sweep returned "0 matched-exemplar families"
because .run/family_hseq.json still listed the fresh cracks as draft-ov077. Regenerated
(matched-sib families 60 -> 63) and the sweep found them — the documented bank-x1 -> regen ->
sweep path (memory crack-wave-sweep-map-regen).
- §86 REPRODUCED CLEANLY: 2 of 3 families templated ~137/137; the third failed ~137/137. Not a
rate — a BIMODALITY. One probe per family, then sweep or skip; never a blended pool average.
- R22 clean-fleet: extract-all 139/139, check-all 140 passed / 0 failed (second clean-tree
verification this session). dedup 1886/0, C1 coverage 239,604/239,604, 0 NON_MATCHING (G4).
- FLEET 81.7 -> 81.9% instr · 89.52 -> 89.60% fn-count · distinct-code 69.3% UNCHANGED — correct
and expected: these are h_seq PURE propagation-class families, and SESSION-20's routing rule says
propagation moves only the DISPLAY metric (members were already counted once via their exemplar).
To move RE-completeness, target byte-VARIANT families. Stated plainly so the next session picks
targets by the metric it means to move.
- drive-by: family_sweep --help crashed (argparse %-expands help text; a literal "0%" needed "0%%").
BANKED (whole-binary byte-gate, the sole arbiter): func_8014D2A0 (80 ins ×138) · func_80158638
(87 ×138) · func_8016B6BC (94 ×138). Stubs in ov_SC01_077: 150 -> 147, 0 new stubs.
R22 CLEAN-FLEET: extract-all 139/139, check-all 140 passed / 0 failed. dedup 1886/0,
0 NON_MATCHING (G4). Fleet 81.7% instr / 69.3% distinct-code / 89.52% fn-count.
- WAVE STOPPED at Drew's request with 15/24 agents returned, ALL 15 status=match. Only the
completed drafts were gated; in-flight ones are still being written (§90d).
- PRE-GATE, both oracles, all 15: match_one MATCH + reloc_verify ALL RESOLVED. Routed 7 plain /
8 to the §81 jtbl carve chain.
- THE BLOCKER, MEASURED: 7 of 7 plain drafts failed PLUMBING, 0 DIFF, 0 compiler walls — the same
shape as SESSION-20's T0.2. §58b applies: the draft sig is byte-TRUTH (it MATCHed), the header
decl is the stale stub-era guess, so conform the DECLS.
- §85 RETURN-AXIS WIDEN, all-or-nothing: 3,471 decl sites / 1,736 files, precondition verified
(ZERO callers consume the return => byte-neutral by construction) + an R32 completion assertion
(old-form decls remaining: 0). func_8014D820's s32 return is load-bearing — forcing `void` costs
2 instructions (302 vs 304), so the decls had to move, not the draft.
TWO HONESTY ITEMS:
1. I REPORTED "0 of 7 banked"; the true number was already 2. My diagnostic pass printed only
lines starting with "- func_" (the failures) and hid its own successes while I read it for
error text. A script that prints only failures cannot tell you it succeeded — the R32
silent-skip shape aimed at my own instrumentation. Ground truth is the stub count (§55b(3)).
2. A REAL FINDING fell out of that mistake: same drafts, same tree, minutes apart — gate_stage's
full ladder banked 0/7 while bare harvest_verify banked 2/7. The LADDER REGRESSED two drafts
the bare gate accepts (§19's "sig_unify regresses already-canonical drafts", one level up, and
the exact mirror of SESSION-20's missing-ladder false 33%). Neither "always ladder" nor "never
ladder" is right — run both, let the byte-gate arbitrate. One build per draft.
OPEN: func_8014D820 still a stub — after the widen its error moved from `conflicting types` to an
assembler-stage failure, not finished diagnosing. Recorded as open, NOT as a wall.
THE BUG (real, found by a wave agent): jtbl_range() ends a carve at the next data dlabel, assuming
every dlabel is an object boundary. spimdisasm can CUT ONE JUMP TABLE IN HALF and emit the tail
under an invented D_ label — func_8012AAAC's 50-word table is jtbl_801D7FB0 (28) + D_801D8020 (22).
The carve then reserves 112 B for an object supplying 200 B of .rodata, shifting every later symbol.
§84-class: match_one is structurally blind; it surfaces only as a whole-binary DIFF.
THE AGENT'S EVIDENCE WAS WRONG (R14): it reported D_801D8020 as having "ZERO xrefs anywhere in the
tree" and proposed deleting the label. It has TWO (.word D_801D8020 and +0x2 in tail.data.s) —
almost certainly spimdisasm mis-symbolizing packed halfword data, but "almost certainly" is not a
gate, and the proposed remedy would have deleted a symbol two emitted words reference. I built the
xref census first, watched it refuse, and only then found the references.
THE GATE USED INSTEAD — the function's own `sltiu N` range check, which gcc emits right before the
indexed load, so the PROGRAM declares its own table length (func_8012AAAC: sltiu 0x32 = 50). Absorb
only when the next label is immediately adjacent, its words are all code addresses in the overlay's
text, and absorbing lands on an EXACT sltiu bound (the SET, not max() — a multi-switch function has
several and no way to say which owns this table).
Three further corrections, each caught by testing rather than assumed:
- the absorption fired and the trailing-pad trim immediately UNDID it (re-trimming against the
first dlabel's 28 words); the trim now sees the whole absorbed table;
- a continuation ends at ITS OWN last .word, not the next dlabel (D_801D8020 ends 0x801D8078; the
next dlabel is 0x801D8158, 224 B on) — using the next dlabel is the assumption being repaired;
- the shortfall warning now fires only on an unambiguous single-bound pairing (it fired ~90 times
across 38 tables before the guard — a warning that fires on ambiguity is noise, not a signal).
VERIFIED: the split table 28 -> 50 words (112 -> 200 B), matching the agent's 3 independent
confirmations; and across 38 jtbls x 6 functions = 228 combinations, EXACTLY ONE range changes —
that table, for its owning function only.
Drew T