Propagation behind every crack, same session (the multiplier the waves exist for). 19 newly-banked
exemplars from waves 1+2, all in the family_sweep lane (0 has_mid_jr):
87 candidate members / 10,212 ins -> 61 BANKED / 26 failed across 39 overlays
The 26 that did not bank are the known plumbing shapes, not codegen: 20 CC1-FAIL + 5 callee
`conflicting types` (func_8017EFA0 x3, func_8012B23C x2) -- the same classes the S40 recovery ladder
already has levers for (§17a-1 no-proto + call-site cast; recover_giant block-scoping). Left open
deliberately rather than force-banked (P9); they are the cheapest fuel on the board next session.
TOOLING GAP RECORDED: the sweep's classifier writes "CC1-FAIL: make: *** Error 33" WITHOUT the actual
cc1 message, so 20 of 26 failures carry no actionable reason. Diagnosing one currently requires
manually splicing the draft into its TU and rebuilding (done twice this session). The classifier
should capture cc1 stderr the way harvest_verify already does -- worth fixing before the next big
sweep, or every CC1-FAIL costs a manual reproduction.
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet 12425854 -> 12432941 instr (+7,087); distinct +6,145 / +51 uniq; fn-count +61.
instr-weighted back to 94.5% ON THE HONEST (post-main-regen) denominator of 13,160,961.
audit-digest OK. 0 NON_MATCHING (G4).
Two ultracode waves over the open-only h_norm clusters (the pool nobody had ever aimed a wave at),
pool VERIFIED from the sigs first (R14).
wave 1 8 targets 8/8 match_one 5/8 gate first pass -> 8/8 after recovery
wave 2 16 targets 16/16 match_one 14/16 gate first pass -> 16/16 after recovery
THE HEADLINE IS NOT 24/24 -- IT IS THAT NOT ONE FAILURE WAS CODEGEN. All six first-pass gate
failures were TU-integration plumbing, each with an already-documented lever:
func_801802EC redefinition of morph_lerp strip the §77 PROBE LAYER (the draft carries types +
a static inline so match_one can compile standalone;
the real TU already defines them -- scaffolding is
not part of the bank)
func_8018B238 conflicting types D_80115158 recover_giant: draft declared it file-scope as a
struct array, TU declares u8[] BLOCK-scope inside
other functions -> block-scope the draft's externs
func_8017EF54 conflicting types (SELF) §37/§124 def-side asm-label alias (TU declares
void f(void) for no-arg callers; byte-true def takes
s32 in $a0; no-proto escape illegal once a param
promotes)
func_80183D78 conflicting types (callee) recover_giant
func_8017F278 conflicting types func_80146C3C §17a-1: the fleet canonical is the NO-PROTOTYPE
form + the intended signature applied AT THE CALL
SITE; a concrete prototype collides with it
(wave-2's 14 first-pass banks needed nothing -- the wave-1 lessons were folded into the prompt)
=> the gate number measures INTEGRATION, not matching. Run the recovery ladder before recording a
wave's yield or the metrics under-report the drafters and send the next wave hunting walls that are
not there. docs/wave-metrics.md S40-1.
POOL VERIFICATION (R14, and it cut both ways): the frontier report's cluster pool MEASURED
1,677 clusters / 5,795 fns / 319,755 ins at a 3.68x multiplier vs its claimed 1,689 / 5,956 /
326,261 at 2.7x -- within 2-4%, and the multiplier is BETTER than claimed. The SAME document's whale
claim was 3/4 wrong. Verify each claim separately; do not accept or reject a source wholesale.
ALSO: 24/24 members propagated from wave 1's 5 banked exemplars (0 failed) -- the same machinery
that returned 0/39 before this session's cast_call_sites fix.
NEW IDIOMS, distilled in-session (R16/R30):
§144 the LITERAL'S SPELLING picks the immediate encoding (`cnt + 0xff` vs `cnt - 1`: mod-256
identical, both one addiu, but gcc emits 0x00FF vs 0xFFFF from the source text)
§145a combine_givs ANCHOR RULE -- the address-giv group anchors on the LAST address-giv in SOURCE
order (record_giv prepends, combine_givs takes the head); store order decides the base and a
wrong choice spawns a third induction register
§145b a bare `p = r;` is a COMBINE BARRIER (can_combine_p/use_crosses_set_p) -- it preserves a
pointer-bump addiu that combine would otherwise fold into every MEM offset
§145c chained assignment `a=b=c=0` emits stores RIGHT-TO-LEFT
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet 12420375 -> 12425854 instr (+5,479); distinct +5,479 / +43 uniq; fn-count +43.
audit-digest OK. 0 NON_MATCHING (G4). Cost: 3.73M subagent tokens across 24 agents, 0 errors.
THE BUG. tools/cast_call_sites.py classifies a declaration line with
^([ \t]*)(extern\s+)?([A-Za-z_][\w \t\*]*?)\b([A-Za-z_]\w*)\s*\(([^;{]*)\)\s*;
Feed it a return statement and `return` is a perfectly good identifier where a type is expected:
return func_8012CB64((s32)out, -0xC0, 0x40, -0x60, 0);
^^^^^^ captured as the return TYPE, func_8012CB64 as the DECLARED NAME
so the "rewrite this decl to canonical" path REPLACED the statement with
`extern s32 func_8012CB64(s32,s32,s32,s32,s32);`, DELETING the return. In C89 a declaration after a
statement is a parse error, so the damage surfaced as a bare syntax error in the DRAFT -- reading as
the draft's fault, not the tool's. 9 of 9 staged members of family 0x801848dc lost their return.
fix: a keyword guard (a declaration's type-specifier can never begin with a statement keyword)
family_sweep --hseq --band all over 5 families: 0/39 -> 18/39 banked (only the guard changed)
⚠️ AND THE TRAP INSIDE THE FIX: the obvious R33 move is "route it through cdecl". CHECKED, and it is
WRONG -- cdecl.parse() is a DECLARATOR-GRAMMAR parser that assumes it was handed a declaration; it
reports `return func_X(...);` as declaring func_X and `if (f(a));` as declaring `if`.
Statement-vs-declaration is a question cdecl does not answer. Routing there would have been a silent
non-fix that looked principled. §134's law still holds for line-SHAPE masking; this is a different
question.
BLAST RADIUS (measured, not assumed -- R14): cast_call_sites is in gate_stage's DEFAULT pipeline
(canon_resident_calls -> cast_call_sites -> sig_unify -> harvest_verify) and has been since Phase 20.
Of 44,833 stored drafts, 318 (0.7%) carry a `return f(...);` line this mis-reads, across 67 callees
(func_8014F468 x41, func_8014F6F4 x37, func_8014F74C x32, ratan2 x25). Every one, every time it
passed the gate pipeline, lost its return and failed as PLUMBING. Part of the historical plumbing
tail is this bug.
ALSO IN THIS COMMIT
- S5 CALIBRATION WAVE (8 agents, ultracode, 1.31M tokens). Pool VERIFIED FIRST (R14 -- Fable's whale
claim was 3/4 wrong): measured 1,677 clusters / 5,795 fns / 319,755 ins at a 3.68x multiplier vs
its claimed 1,689 / 5,956 / 326,261 at 2.7x -- its numbers hold, and the multiplier is BETTER.
Result: 8/8 match_one MATCH (close=0), and 5/8 banked whole-binary -- the §52b/§61 gap is
integration, not codegen. Banked: func_801822E0 func_8017EC98 func_801851A8 func_80189A34
func_80188E10 (693 ins x1 before propagation). Not banked: func_8018B238 (FAILED),
func_8017EF54 + func_801802EC (NEAR) -- drafts kept in .run/wave-s40/ for recovery.
- 18 member-banks from the re-run sweep (the cross-address free-h_exact pool: h_exact-identical at
DIFFERENT addresses, which dedup_propagate correctly refuses since it assumes position-locking --
family_sweep is the right lane).
- cookbook §143 (this bug + the cdecl trap + the blast radius); index regenerated.
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet 12419169 -> 12420375 instr; distinct +1,526 / +5 uniq; fn-count +23. audit-digest OK.
0 NON_MATCHING (G4).
NEW IDIOM FROM THE WAVE, not yet folded into §31 (agent was told to write only its draft): a byte
counter must be spelled `cnt + 0xff`, NOT `cnt - 1`. Both are mod-256 identical and both compile to
one addiu, but gcc-2.7.2 picks the immediate encoding from the SOURCE SPELLING (0xFFFF vs 0x00FF).
Also flagged: .run/ghidra_c/func_8017EF54.c is a stale decompile of the WRONG function.
Measured the h_exact free pool from the bytes rather than trusting the frontier report's
numbers (R14 — its whale claim was 3/4 wrong: it said the whale was open in all four SC07
overlays; three were already banked and I closed the fourth earlier this session).
MEASURED: 215 open function-instances / 8,763 instructions are byte-identical (h_exact,
including reloc payloads) to an already-matched function. ONE class is 86% of that pool:
func_801758FC — 55 ins, same address in all 138 overlays, matched in ov_SC01_000 only,
OPEN in the other 137 => 7,535 instructions.
h_exact means identical INCLUDING jal/lui/%lo reloc immediates, so the matched body compiles
byte-identically at every member with NO remap (dedup_extend's correctness argument, §14).
dedup_propagate --addr authored it once as DEFINE_func_801758FC() in engine_core.h and
instantiated it at all 137 open sites in address order.
[ OK ] 138 overlays byte-identical after propagation; 1 new group in config/dedup.us.yaml
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet instr 12411467 -> 12419002 = +7,535 EXACTLY; fn-count +137; instr-weighted crosses to
94.5%. distinct-code unchanged BY DESIGN -- the class was already matched in ov_SC01_000, so
the 137 add fleet instructions but no new DISTINCT function. audit-digest OK. 0 NON_MATCHING.
Note this function had been sitting in the stored-draft backlog for ov_SC06_030 and
ov_SC07_010 and re-gated "no" earlier tonight -- because gating a DRAFT is the wrong move for
an h_exact class. The right move is propagating the already-MATCHED body. Same function, two
routes, and only one of them is free.
Remaining free pool after this: 78 instances / 1,228 ins across 32 classes.
The 39 draft-exemplar families all have their exemplar still OPEN in ov_SC01_077 -- a
draft-exemplar family cannot propagate until its head banks. Re-gated the newest stored
ov077 draft per head, in 4 small batches (§61: a wide harvest broke a TU in S38).
Set aside the top 4 heads (65% of the pool's weight, all known-hard): func_801412A8 +
func_80178004 ARE S6's two giant walls (198x138 + 165x138 = 50,094 ins riding on 2 cracks),
func_8017C974 is today's byte-proven close=47, func_8017C294 its 246-ins neighbour.
batch 0 1/9 batch 1 3/9 batch 2 4/9 batch 3 0/8 = 8/35 (23%)
BANKED: func_8017EC7C func_8018281C func_801820DC func_80182988 func_80183BAC
func_80183AF0 func_80183CF4 func_80182E7C
(+474 ins x1 now; ~1,441 ins of templatable weight behind them once their families propagate.)
CALIBRATION REFINEMENT (docs/calibration.md, S39): this population re-gates at 23%, vs 8%
for the general stored pool and 4/6 for fresh post-repair drafts. Three different populations,
three different rates -- which is exactly why the rule is "re-gate what a repair plausibly
touched", not "re-gate the ledger". ov_SC01_077 is the split-heaviest overlay, so the S38
alias-deletion repair plausibly touched all of these.
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet 12410275 -> 12410749 instr (+474), distinct +474 / +8 uniq, fn-count +8. audit-digest OK.
0 NON_MATCHING (G4).
Tested whether decision-log A10 ("stored drafts re-gate at 0/958", measured in T1) survives
S38's tool repairs. Three populations, plain re-gate, no draft edits:
fresh wave-6 drafts (diagnosed "blocked on a class") 4/6
stored pool, unbiased sample (every 96th of 1,155) 1/12 <- hit was in a REVERTED overlay
the two REVERTED overlays, targeted 3/17
A10 BROADLY STANDS. ~8% on the general stored pool is not a harvest, and a 1,155-wide sweep
(= 1,155 whole-binary builds) is not justified by it. Do NOT generalise the fresh-draft rate
(4/6) onto the stored pool -- different populations. The honest rule is narrower and cheaper:
after a tool repair, re-gate the drafts THAT DEFECT plausibly touched, targeted by its
blast radius -- not the whole ledger. (R35 applied to the backlog, not just to metrics.)
BANKED (+146 ins): ov_SC06_030 func_80161208 + func_80162CCC; ov_SC07_010 func_801506A4 +
func_8016F0AC. R22 clean-fleet 140 passed, 0 failed of 140 -- which also proves byte-neutral a
fleet-shared engine_core.h edit the bank required (extern s32 func_801506A4(s32,s32) -> the
no-prototype form), reaching all 138 overlays (T2 blast radius).
Fleet 12410129 -> 12410275 instr; distinct +95 / +1 uniq; fn-count +4. audit-digest OK.
Also documents the LEDGER MECHANICS in calibration.md (Drew asked): .run/backlog.jsonl is
append-only and nothing is deleted on bank -- open-ness is DERIVED from corpus.stubs at every
read (load_best drops now-banked rows per-binary, P9) and `make report` runs `backlog.py prune`.
Membership is therefore self-maintaining and currently clean: 863 rows, 0 already-banked, 14
duplicate-addr (was 6,867 rows / 98% banked before Phase-29 compaction). What pruning does NOT
re-validate is the VERDICT on surviving rows -- closeness + residual class are as old as the
tooling that wrote them (Phase 28 found a corrupt one: func_80178004 close=0 -> 91). That is
the staleness that matters, and it is exactly what this probe measured.
Propagation behind the crack banked this session. jtbl_family_bank.py over the 4 open
h_seq siblings of func_801878E8 (513 ins each):
ov_SC03_001 BANKED ov_SC03_124 BANKED
ov_SC04_019 BANKED ov_SC05_017 BANKED
ROUTE NOTE (§53, worth keeping): family_sweep --hseq REFUSED this family by design --
has_mid_jr => it needs the jtbl carve, not the remap sweep, and the interlock says plainly
that "a 0% from this path would be a TOOL artifact, not a wall". Taking the refusal at face
value and using the named tool banked 4/4 first try. This is the same lesson as the rest of
the session from the other side: the instrument told the truth about its own limits.
jtbl_family_bank also enforces a CLEAN tree (it reverts from HEAD per sibling, so an
uncommitted prior bank would be destroyed) -- which is why the ×1 banks committed first (H4).
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140
(each sibling carves its own jtbl => config changed => fleet blast radius). Fleet
instr-weighted 12408077 -> 12410129 = +2,052, exactly 4 x 513; distinct +1,539 / +3 unique
fns (the 4th sibling shares an h_exact class already matched); fn-count +4. audit-digest OK.
0 NON_MATCHING (G4).
Session running total: +4,727 instructions (whale 770 + 4 drafts 1,905 + family 2,052),
12405402 -> 12410129, every step R22 clean-fleet 140/140.
The 6 still-open wave-6 drafts were triaged against S38's own diagnosis table; 4 banked,
R22 clean-fleet 140/140.
func_801919A0 ov_SC06_032 710 ins (was: undefined ref func_8018B878 -- "alias class")
func_80189030 ov_SC03_001 557 ins (was: undefined ref func_80186F88 -- "alias class")
func_801878E8 ov_SC04_018 513 ins (was: undefined ref func_801848DC -- "alias class")
func_8018A564 ov_SC02_027 125 ins (was: CC1-FAIL Error 33)
THE FINDING: all four banked with NO change to the drafts. S38 recorded them blocked on a
class that needed cracking ("cracking this one class frees 6 drafts at once"); they had
ALREADY been freed by S38's own tool repairs -- the jr_isolate_all/overlay_src_split
alias-DEFINITION-deletion blindness and harvest_verify._reload_corpus. The drafts were
correct all along; the instruments were failing them. That is the FIFTH recorded "wall"
this phase to resolve to our own tooling.
=> RE-GATE STORED DRAFTS AFTER ANY TOOL REPAIR before treating a stored verdict as a
fact about the code. A verdict is only as current as the instrument that produced it
(R35 applied to the backlog, not just to metrics).
Each bank also performed a jtbl carve, so config/ changed => fleet blast radius => full R22
(clean + extract-all + check-all) = 140 passed, 0 failed of 140.
Metrics move exactly as the model predicts: instr 12406172 -> 12408077 = +1,905, the exact
sum of the four (710+557+513+125); distinct +1,905 / +4 unique fns; fn-count +4.
audit-digest OK. 0 NON_MATCHING (G4).
LEFT ON THE BACKLOG as genuine codegen residuals, not forced (P9):
func_8017C974 (ov_SC01_077, 947 ins, close=47, REGALLOC-PERM, 12 permuter variants inert)
func_80188C68 (ov_SC03_124, 551 ins, close=370, the only target with no twin anywhere)
NEXT: the func_801878E8 family (4 open siblings x 513 ~= +2,052). family_sweep --hseq
correctly REFUSED it via the §53 interlock (has_mid_jr => jtbl carve route; "a 0% from this
path would be a TOOL artifact, not a wall"), and jtbl_family_bank.py requires a clean tree
because it reverts from HEAD per sibling -- which is why this commit lands first.
Closes the first of S38's two reverted R22 failures. ov_SC07_010 was the lone overlay
still shipping func_80144B9C (770 ins) as INCLUDE_ASM while the other 137 banked it.
Its _jr_80140608 object ran 0x184b0..0x2c2f4 straight through the whale; the sibling
ov_SC07_006 carves the same span into _o0d (0x1ca44) + _jr_801457A4 (0x1d64c). Note
0x1ca44 + 0x80128158 = 0x80144B9C exactly.
tools/o0_subsplit.py ov_SC07_010 --lo 0x80144B9C --hi 0x801457A4
-> 1 unmatched stub, 0 ALREADY-MATCHED in range (so no §126 island; K=0 => 3 regions)
-> split BYTE-NEUTRAL first (d7b5875d), then banked via ../shared/func_80144B9C.h
The S38 cause ("its -O0 split reused an EXISTING _o0c instead of a fresh _o0d") did NOT
recur: o0_subsplit.free_letters derives the unused suffix (_o0c is free in THIS overlay).
Two decl conflicts on the way, enumerated with `cdecl` in ONE pass (R33) rather than one
build at a time — of the whale header's 94 symbols the §8b carried layer re-declares 3,
and 2 conflict: D_801274D0 (layer `s32 (*)(s32)`) and D_801274CC (layer `void *`) vs the
header's canonical `s32`. Dropped both: nothing in the region uses them, they are carried
from an earlier region of the old object, and 0 of the 137 other whale-including files
carry either. Decls emit no code => byte-neutral (§8c), and byte-gated.
ov_SC06_030/func_8017E120 needed NO work — it is already banked (defined at
ov_SC06_030_jr_8017C8D0.c:3491). S38 reverted the surrounding batch, not that function.
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140
(config changed => fleet blast radius, R22 mandatory). Fleet instr-weighted
12405402 -> 12406172 = +770, exactly the whale's size. distinct-code unchanged by design:
that h_exact class was already matched via the other 137, so the 138th adds fleet
instructions but no new DISTINCT function. audit-digest OK (the new S1e gate, on its first
real use). 0 NON_MATCHING (G4).
Metric note (R30, same class as S1e): a body banked by #include-ing a shared header is
invisible to fn-count's NUMERATOR (the definition is not in the .c) while its stub leaves
the denominator -- 341186/353718 -> 341186/353717. The weighted metrics counted it
correctly because they derive from corpus.stubs, not re-parsed C. Trust the weighted pair.
Still open from S3: the 61 SC07 -O0 members (untouched).
Applied the def-side asm-label alias transform to all 971 staged member drafts (of 997; the rest
had no func_<ADDR> definition head) and gated them: 192 source files changed, ~5,985 insertions.
R22 clean-fleet 140/140 AFTER reverting ov_SC06_030 (below).
METRICS, AS MEASURED — one of them moved the WRONG WAY and I cannot yet explain it:
fn-count 96.32% -> 96.46% (+483 fns)
instr-weighted 94.4% -> 94.4% (+2,990 ins)
distinct-code 89.3% -> 89.2% (78,025 -> 77,952 uniq, -73)
A revert of ONE overlay to HEAD cannot lose 73 distinct functions, so something else is going on.
LEAD (NOT CONFIRMED): progress.py's definition scanner records the identifier immediately before the
paren (SIG at tools/progress.py:423), so an alias definition `void aF80146A6C(...)` is recorded as
`aF80146A6C`, not as func_80146A6C. That same scanner's docstring documents this exact blindness for
K&R defs, where it "silently erased ~190k banked instructions". BUT that lead does not explain why
fn-count ROSE while distinct-code FELL — they should move together under a pure naming artifact.
DO NOT treat the alias harvest's yield as established until this is resolved: the bytes are proven
(R22), the ACCOUNTING is not.
ov_SC06_030 REVERTED: `D_800AF648' undeclared in func_8017E120 — a draft that gated fine broke once
the REST of the harvest landed in the same TU (its declaration presumably displaced by another
banked draft's preamble). SECOND instance today of "per-binary acceptance is not a fleet claim"
(§61), after ov_SC07_010. In a WIDE harvest it is not even a per-TU claim, and only the clean-tree
R22 catches it. The narrow single-family run (138/138) was clean precisely because it was narrow.
Family 0x80146ab4 (18 ins, x138, PURE) had been failing 0/138 with `conflicting types for
func_80146A6C` — 208 of the ~398 conflicts in the sweep residue, its single dominant blocker.
DIAGNOSED BY READING THE DRAFT, after three levers were eliminated by measurement:
draft def : void func_80146A6C(s16 a0, s32 a1, s16 a2, s16 a3, u16 a4, s32 a5, s32 a6)
TU decl : extern s32 func_80146A6C(s32 a0, void *a1, s32 a2, s32 a3, s32 a4, s32 a5, s32 a6);
The NARROW PARAMS are the wall: C's default argument promotion means s16/u16 cannot agree with an
s32 prototype, and the `()` no-prototype escape is ILLEGAL precisely when a param promotes. Neither
declaration side can move.
- cast_call_sites: already on by default; wrong axis (fixes CALLEE decls, not the def's own).
- --normalize-self-decls: 0 banks + non-neutral reverts; wrong axis (the target's decl in callers).
- --fix-def-sig: measured 0/138, error UNCHANGED — it cannot reconcile a promoting param at all.
THE ESCAPE (§37/§124, S33-proven on func_80147364 — definition (u16,u16) vs 4,046 fleet decls,
banked x137 first try; 1,725 in-tree precedents): give the DEFINITION a private C identifier and
bind the emitted symbol with a GNU asm label, so the TU's declaration never meets the definition and
its type becomes irrelevant. Zero blast radius on every caller; byte-neutral by construction.
void aF80146A6C(<byte-true params>) __asm__("func_80146A6C");
void aF80146A6C(<byte-true params>) { ... }
RESULT: 138/138 banked, ~2,484 instructions, ZERO agent tokens. R22 clean-fleet 140/140.
.run/alias_defs.py applies the transform to a staged draft set.
NEXT: this is a CLASS lever, not a one-family fix — generalise it across the remaining sweep residue.
func_80144B9C (770 ins) was matched in 134/138 overlays and open in the four SC07s — 3,080
instructions of code BYTE-IDENTICAL (h_exact, reloc payloads included) to what was already banked,
blocked by a missing file boundary. Now banked in ov_SC07_006 / _007 / _011 for ~0 agent tokens.
R22 clean-fleet 140/140.
THE PLAN'S FRAMING WAS WRONG. This was recorded as "the SC07 carve defect (T2 Arm-A %lo +0x20)".
The carve was never broken: o0_subsplit reported `split byte-neutral` on the FIRST attempt in all
four. The real blocker is that carving the whale out of a jr file makes jr_isolate_all hoist the
parent's file-scope decls into the new region as its `ambient` set — so for the first time the
fleet's loose-typed spellings share a TU with the shared header's (`extern void *D_801274CC` vs
`extern s32 D_801274CC`). In the 134 working overlays the whale sits in a CLEAN -O0 file (common.h +
the header, nothing else) and the two never meet. Fix: drop, in that one file only, the ambient
decls the header already declares — the header being the byte-proven side.
Three iterations, each exposing the next layer of the ambient set, every one a DECLARATION:
1. data symbols (D_80126B58, D_801274CC, D_801274D0)
2. function symbols (func_801336E8, func_8005C324)
3. the alias form terminated by a trailing COMMENT, which an endswith(';') test skipped —
the §134 comment-blindness shape for the THIRD time today.
ov_SC07_010 REVERTED and left open (hence 137/138). Its split landed in an EXISTING _o0c file
rather than a fresh _o0d, producing region _jr_801457A4 whose asm dir splat never generated. It
passed its per-binary build and FAILED the clean-tree R22 — the first R22 failure of the session,
and precisely why a per-binary pass is not a fleet byte claim (§61). Committing on that per-binary
"BANKED" would have shipped a broken overlay.
jtbl_family_bank (the §53 carve path; family_sweep --hseq refuses has_mid_jr families
BY DESIGN — a 0% from the carve-less tool is an artifact, not a wall). Each sibling
individually byte-gated: carve -> extract -> remap -> whole-binary build, kept iff
byte-identical else reverted. Committed per family because jtbl_family_bank requires a
clean tree between families. R22 clean-fleet runs once over the batch.
jtbl_family_bank (the §53 carve path; family_sweep --hseq refuses has_mid_jr families
BY DESIGN — a 0% from the carve-less tool is an artifact, not a wall). Each sibling
individually byte-gated: carve -> extract -> remap -> whole-binary build, kept iff
byte-identical else reverted. Committed per family because jtbl_family_bank requires a
clean tree between families. R22 clean-fleet runs once over the batch.
jtbl_family_bank (the §53 carve path; family_sweep --hseq refuses has_mid_jr families
BY DESIGN — a 0% from the carve-less tool is an artifact, not a wall). Each sibling
individually byte-gated: carve -> extract -> remap -> whole-binary build, kept iff
byte-identical else reverted. Committed per family because jtbl_family_bank requires a
clean tree between families. R22 clean-fleet runs once over the batch.
jtbl_family_bank (the §53 carve path; family_sweep --hseq refuses has_mid_jr families
BY DESIGN — a 0% from the carve-less tool is an artifact, not a wall). Each sibling
individually byte-gated: carve -> extract -> remap -> whole-binary build, kept iff
byte-identical else reverted. Committed per family because jtbl_family_bank requires a
clean tree between families. R22 clean-fleet runs once over the batch.
Families that returned 0/N before the 895-type lift now bank: 97 member-matches across 137 families
(1,138 failed; skipped 186 STRUCT-class by design, 106 unresolved-immediate, 6 not-stub).
R22 clean-fleet 140/140. Fleet 94.2 -> 94.3% instr / 88.9 -> 89.1% distinct / 96.29 -> 96.32% fn.
RESIDUE PRICED FROM THE SWEEP'S OWN .classified.txt PAYLOADS, not inferred: in the 400 most recent
failure records, 133 are genuine DIFF and the clear majority are `conflicting types for <sym>` —
the §103/§20 extern-conflict class, across ~12 overlays. That confirms S1b (wire reconcile_tu /
cast_call_sites into the --hseq path) is the correct next lever, and it is now justified by
measurement rather than by the plan's projection.
Method note worth keeping: those per-member diagnoses have been written on every sweep run for a
month and were never read — including by me, until after I had spent two probes and a manual
--stage-only round rediscovering one of them. Every remaining task now starts by reading the payload.
The free-sweep "wall" was a C parse error: a remapped member body names the EXEMPLAR's TU-local
types, which are undeclared in the sibling's TU, so gcc-2.7.2 parses the declarator as an expression
and dies before ever reaching codegen. extract_unit does carry typedefs, but only ones immediately
preceding the function in the preamble — types declared elsewhere in the exemplar's TU are missed.
Rather than patch the scanner per-family, remove the class: lift every liftable local type into the
shared header once. 895 types lifted, 6,196 local definitions stripped across 1,259 files.
R22 clean-fleet 140/140.
EXCLUDED s8/s16/s32/u8/u16/u32/f32/s64/u64/f64 — lift_types classified those common.h scalars as
liftable and lifting them would have been actively harmful. The tool's own visibility guard kept 8
local defs in src/ov_SC01_077/ov_SC01_077_o0.c, which does not include engine_types.h (stripping a
type out of a TU that cannot see the replacement DELETES it, and the link error that follows names
an unrelated data symbol).
Mechanism proven before scaling: lifting just 3 types took 0x801833f0's family from 0/6 to 6/6.
family_sweep --hseq returned 0/6 on 0x801833f0 (328 ins, PURE, matched exemplar) and I recorded it
as evidence that h_seq families do not template. It was a C PARSE ERROR: the remapped member body
carries the EXEMPLAR's TU-local type names (PTag_801833F0 / Ft4_801833F0 / Drm_801833F0), which are
declared only in ov_SC02_028's TUs. Undeclared type -> gcc-2.7.2 parses the declarator as an
expression -> "parse error before `vtx'" two lines later. Never reached codegen.
Lifting the three types to src/shared/engine_types.h (lift_types --apply; each had ONE canonical
definition, no variants) turns the same sweep into 6/6 banked. R22 clean-fleet 140/140.
This is the §20 propagation cap resurfacing on the h_seq sweep path, where nobody had checked for it.
MY ERROR, RECORDED (R37/R14): I claimed in the S38 checkpoint and in commit commit:1410 that
"family_sweep reports banked/failed WITHOUT the per-member build error". That is FALSE. There are
23,211 .run/hseq_failed.*.classified.txt files on disk; the diagnosis for BOTH of today's zeros was
written by the sweep itself at probe time (0x80128c98's says "PLUMBING: conflicting types for
`cdFileLocTable'"). I asserted a tool limitation without checking for it, and then spent two probes
plus a manual --stage-only round rediscovering what was already in a file. Probe before costing.
ROOT CAUSE (byte-witnessed, P30 S38 — the fifth tool with this same blindness).
A function banked under the §37/§73 DEFINITION-SIDE ASM-LABEL ALIAS form is spelled with a private
C identifier and bound to its real symbol by a GNU asm label:
void aF8018A860(s32, s16 *, u8 *, u8 *) __asm__("func_80183AF8"); <- decl, stays in preamble
void aF8018A860(s32, s16 *, u8 *, u8 *) { ... } <- THIS emits func_80183AF8
overlay_src_split.addr_of() resolves `func_<hex>` arithmetically and everything else through `syms`.
`aF8018A860` matches NEITHER, so it returned None — and partition() keeps only items with a
resolved address, so the definition was dropped from EVERY region. The file was then rewritten
without it and nothing said so. One carve of ov_SC02_028 deleted the definitions emitting BOTH
func_80183AF8 and func_80184268; the overlay stopped linking with `undefined reference`, and six
wave-6 drafts were written off against that as a plumbing/compiler wall.
TWO FIXES:
- CAUSE: overlay_src_split now builds an asm-label alias map from the source and resolves a
definition through its EMITTED SYMBOL rather than its C name (verified: aF8018A860 -> 0x80183AF8,
aF8018AFD0 -> 0x80184268 — exactly the two symbols the link was missing).
- SILENCE: partition() and jr_isolate_all._partition() now REFUSE to rewrite a file when any
construct's address does not resolve (R32), instead of discarding it. That guard alone would
have surfaced this the first time it happened.
RESULT: 3 of the 6 alias-class wave-6 drafts bank immediately, for ZERO agent tokens —
func_801884D8 (137 ins) · func_80180B04 (251) · func_801380E0 (438). R22 clean-fleet 140/140.
The other 3 (the three LARGEST: 557/513/710 ins) have a second, size-correlated cause — open.
NOTE FOR THE FLYWHEEL: family_remap._alias_decl_for ALREADY handled this exact form, and its
docstring records the identical lesson ("that blindness was the WHOLE of the h_seq sweep's 137 'no
matched unit' skips. The tool, not the compiler (R35)"). The fix was never propagated. The alias
form needs ONE shared oracle, the way §134 comment-masking ended up on cdecl._mask — five tools
have now independently rediscovered it.
jtbl_family_bank (the §53 carve path; family_sweep --hseq refuses has_mid_jr
families by design). Each sibling individually byte-gated: carve -> extract ->
remap -> whole-binary build, kept iff byte-identical else reverted. Committed here
because jtbl_family_bank requires a clean tree between families (its per-sibling
revert restores from HEAD). R22 clean-fleet runs once over the whole batch.
jtbl_family_bank (the §53 carve path; family_sweep --hseq refuses has_mid_jr
families by design). Each sibling individually byte-gated: carve -> extract ->
remap -> whole-binary build, kept iff byte-identical else reverted. Committed here
because jtbl_family_bank requires a clean tree between families (its per-sibling
revert restores from HEAD). R22 clean-fleet runs once over the whole batch.
jtbl_family_bank (the §53 carve path; family_sweep --hseq refuses has_mid_jr
families by design). Each sibling individually byte-gated: carve -> extract ->
remap -> whole-binary build, kept iff byte-identical else reverted. Committed here
because jtbl_family_bank requires a clean tree between families (its per-sibling
revert restores from HEAD). R22 clean-fleet runs once over the whole batch.
jtbl_family_bank (the §53 carve path; family_sweep --hseq refuses has_mid_jr
families by design). Each sibling individually byte-gated: carve -> extract ->
remap -> whole-binary build, kept iff byte-identical else reverted. Committed here
because jtbl_family_bank requires a clean tree between families (its per-sibling
revert restores from HEAD). R22 clean-fleet runs once over the whole batch.
jtbl_family_bank (the §53 carve path — family_sweep --hseq correctly REFUSED these as has_mid_jr
families, warning that a 0% from the non-carve path would be a TOOL artifact, not a wall).
func_8017FEE0 (299 ins, cross-address family of 19 open siblings): 15 BANKED, 4 gate-fail.
Each sibling individually byte-gated by jtbl_family_bank (carve -> extract -> remap -> build, keep
iff byte-identical else revert). R22 clean-fleet runs once over the whole propagation batch; this
commit exists because jtbl_family_bank REQUIRES a clean tree between families (its per-sibling
revert restores from HEAD, so an uncommitted prior family would be destroyed).
THE DEFECT CHAIN (byte-witnessed, both ends fixed):
1. harvest_verify._reload_corpus re-applied the `--src` filter AFTER a jtbl carve. Following a
carved stub to its NEW TU is that function's entire documented purpose, and it was deleting the
very stub it had just followed. Then:
_stubs loses fn -> render() raises KeyError -> UNCAUGHT -> _jtbl_restore(snap) never runs
-> the carve is STRANDED in config/ + src/ -> every LATER group in the same gate run then
built against a tree the earlier crashes had mutated.
line 136 already calls --src "an optional filter, not a location oracle"; this was the one place
treating it as one. Fix: the filter never drops a draft under verification, wherever it now
lives, + an R32 loud report if a working stub vanishes across a reload (which also repairs
_touched/baseline — a carved fn missing from _stubs left its new TU unbaselined, so the revert
path could not have restored it either).
2. .run/s6f_gate.py never checked the child's returncode — it grepped stdout for VERIFIED:/FAILED:
and booked "neither" as NOTHING, printing a clean-looking tally over 10 missing verdicts. This
is the §136a defect I logged against my own capture tool last session, in the gate itself.
Fix: 1:1 accounting assertion (banked+failed+no-verdict == drafts), the child's rc + output tail
on anything unaccounted, and exit 1 — a crashed child may have stranded a carve, so it must
never look like success.
PROOF THE FIX IS NOT COSMETIC: func_8017EA84 (579 ins) now carves and banks BYTE-IDENTICAL. The old
tool reported it as nothing at all.
BANKED 7 (R22 clean-fleet 140/140 from `make clean` + extract-all + check-all):
func_8017EA84 ov_SC02_000 (579) · func_8017FEE0 ov_SC02_026 (299) · func_80181CE4 ov_SC03_111 (491)
func_80183AE0 ov_SC03_112 (240) · func_80184C74 ov_SC06_018 (288) · func_80180F98 ov_SC03_097 (263)
func_801841C8 ov_SC02_035 (44)
MY OWN ERROR, RECORDED (R37/R14): after reverting the stranded carves I re-extracted ONE overlay,
not all 16 — the Phase-20 R22 corollary (a reverted CONFIG needs a `make extract`, not just a
revert) which I know and skipped. Run 2 therefore read WORSE than run 1: three genuinely-banked
functions failed against stale asm. Re-extracting the 16 touched binaries produced the honest run.
A gate result measured against stale asm is not a measurement (R35).
.run/w6_diag.py: run the REAL gate path for one (ov,fn) with the child's full output. s36_capture.py
splices without the carve, which is the wrong path for a table-bearing fn (§61b: the carve must
follow the splice) and produces a failure that is an artifact of the diagnosis.
Fleet 96.27 -> 96.28% fn-count / 94.1% instr / 88.6 -> 88.7% distinct (77,765
uniq). R22 clean-fleet: 140 passed, 0 failed of 140. dedup 1910/0.
16 targets / 16,884 templatable ins. 19 agents, 2.71M tokens, 82 min wall.
The gate banked 16/16 — the FIRST perfect gate of the session, and the first
needing NO reconcile at all. Sweep: +26 members / 3 failed across 17 overlays.
NEW: docs/wave-metrics.md — the wave-by-wave performance log, with the derivation
commands so future rows are COMPUTED, not hand-transcribed (R33). Four findings,
each recorded with its caveat rather than as a bare number:
1. THE PROMPT IS THE LEVER, AND THE AGENTS WRITE IT. Bank rate 76 -> 77 -> 100
-> 100 -> 100% with models and gate held constant. The jump was STEP 0 (a
magic-literal grep of src/, ahead of engine_core.h) — which came from a
wave-2 agent's index_gap report. Caveat recorded: waves 3-5 targets also
trended easier, so the mechanism is the durable claim, not the exact %.
2. pipeline() vs batched parallel(): 136 min/14 targets -> 82 min/16 targets,
parallelism 2.5x -> 3.8x. The two-batch design was a hard barrier with 37-50
min dead gaps; the harness already caps at 16 so it bought nothing. Floor
recorded honestly: the slowest agent is still ~50 min of real match_one
iteration, so the lever there is target SELECTION, not concurrency.
3. ECONOMICS: ~170-300k tokens per banked head in the stable regime — but a head
is not the unit of value. Head + propagated members is, and sweep yield is
BIMODAL not average (21/21 vs 18/165), because it is a property of the FAMILY.
Averaging those two predicts nothing.
4. A perfect gate is a signal the prompt rules landed. Waves 1-4 each needed 1-2
post-gate reconciles; wave 5 needed zero. The reconcile lane is the fallback,
not the plan. Lifetime 21/22.
Fleet: R22 clean-fleet 140 passed, 0 failed of 140. dedup 1910/0.
14 targets / 16,844 templatable ins. 17 agents, 3.0M tokens. Claimed 14/14; the
whole-binary gate banked 13, the 14th on reconcile. Sweep: +26 members / 0 failed
across 18 overlays. Reconcile lane 21/22 lifetime.
STEP 0 HAS BECOME THE AGENTS' DEFAULT MOVE. Nearly every wave-4 verdict cites the
cross-overlay magic-literal grep BY NAME, several reporting `index_gap: none`
because it resolved the target in one pass with no cookbook derivation needed:
- func_8018BED0: grep 0xE100000A -> func_80188C04 (ov_SC03_089), verbatim, MATCH first try
- func_8018BAB4: grep D_800A6610/D_800B9A02 -> func_801887E8, verbatim + callee swap
- func_8017ED54: grep named all 5 family members -> reused func_8017D9F0's body, 14 data remaps
- func_8017C290: grep found byte-identical twins ALREADY banked in two other overlays
Bank rate by wave, same models + same gate, prompt the only variable:
76% -> 77% -> 100% -> 100%.
THE ONE FAILURE IS THE §138 RECONCILE-DIRECTION RULE, in its purest form:
`redefinition of struct B16_8018A758` — the agent copied its sibling's struct tag
verbatim, and that sibling had banked into the SAME TU earlier in THIS wave. Decl
ABOVE the splice => DELETE the duplicate (do not rename it). Worth noting the
mechanism: a wave can create its own reconcile work when two targets share a TU.
func_8018A808's own family swept 0/14 — its members are the per-location kind
that do not template (the settled h_seq ceiling), not a plumbing failure.
Fleet 96.24 -> 96.25% fn-count / 94.0% instr / 88.4 -> 88.5% distinct.
R22 clean-fleet: 140 passed, 0 failed of 140. dedup 1910/0.
13 targets / 17,644 templatable ins. 14 agents, 2.7M tokens. Claimed 13/13;
the whole-binary gate banked 12, the 13th on reconcile (another §37/§124
SELF-axis alias — the TU declares `(void)`, the def takes an s32). Reconcile
lane 20/21 lifetime. Sweep: +21 members / 0 failed across 16 overlays.
THE FLYWHEEL, MEASURED ACROSS THREE WAVES (same models, same gate):
wave 1 baseline prompt 15/17 claimed -> 13 banked (76%)
wave 2 + the S33 rules 11/13 -> 10 (77%)
wave 3 + S34 magic-grep as STEP 0 13/13 -> 13 (100%)
Multiple wave-3 agents report the cross-overlay magic-literal grep landing the
answer on the FIRST search. One found a banked twin whose own header comment
already documented it as byte-identical to the new target, so the body
transferred verbatim with only file-local type suffixes renamed. That is the
wave-2 discovery paying off one wave later (R16).
Sweep quality also differed for a reason worth keeping: 21/21 here vs 18/165 in
wave 2. Wave 2's two big families are the per-location kind I then probed and
ruled out (BUILD OK + byte diff = genuine per-member codegen, not plumbing);
wave 3's are genuinely templatable. The sweep rate is a property of the FAMILY,
not of the wave.
TOOLING: an agent left 8 scratch files (test_licm*.c) in the drafts dir and the
gate driver died on `int('full', 16)`, taking the whole gate with it. Hardened to
treat a non-conforming filename as a NAMED, COUNTED skip rather than a crash
(R32) — a drafts dir is agent-writable by design, so it must not be trusted to
contain only deliverables.
Fleet 96.24% fn-count / 93.9 -> 94.0% instr / 88.4% distinct. R22 clean-fleet:
140 passed, 0 failed of 140. dedup 1910/0.
WAVE 2: 13 targets / 37,943 templatable ins. 19 agents, 4.5M tokens. Claimed 11
MATCH; the whole-binary gate banked 9, +1 on reconcile (func_8017E5D0 via the
§37/§124 DEFINITION-side alias — the TU declares it `(void)`, the byte-true def
takes a pointer). Reconcile lane now 19/20 lifetime. 18 members swept.
THE FINDING (an agent caught a hole in our own procedure). §136c's search order
— engine_core.h near-twin -> same-TU banked sibling -> the .s — is entirely
SAME-TU or SHARED-HEADER scoped, so no step can reach a banked twin in a
DIFFERENT overlay's TU. But the large template classes live cross-overlay by
construction. func_80188C04 (328 ins) turned out byte-identical to an
already-banked func_801833F0 in ov_SC02_028, and ONE command found it:
`grep -rn "E100000A" src/` — a magic word lifted from the target .s. The body was
then reused verbatim, only file-local suffixes renamed. Promoted to STEP 0 of
§136c, ahead of engine_core.h.
That compounds with the manifest finding this session: the family map's
`exemplar` is an IN-FAMILY pointer, so a family whose twin is banked elsewhere
looks un-cracked — and the pointer can itself name an ALREADY-BANKED instance,
hiding the family from any ranking built on it. Derive open sites from
corpus.stubs over the member list instead. Measured on this wave: ranking off the
map's exemplar gave 16,696 templatable ins; deriving from corpus.stubs gave
41,023, including a 55-ins family open in 138 overlays and a 46-ins one in 133.
HONEST ON THE SWEEP: those two big families templated 18/165. That is the known
h_seq refusal ceiling, not a new wall. One agent reported "all 10 members
distance 0" — that is NORMALIZED distance, not h_exact, which is why
dedup_propagate correctly answered reach<2. Do not read a normalized-distance
claim as an h_exact guarantee.
LEDGERED (real residual, not paperwork): func_8017F7B4 — needed its sibling's
type names AND a data asm-label alias for a u8-shaped symbol, and still refuses.
Plus func_8017C294 (DIFF close=12: 4 register/schedule permutations + a frame
where I can get the 0x138 size OR pEnd's slot at 0x108, not both) and
func_801898E4.
Fleet 96.23 -> 96.24% fn-count / 93.9% instr / 88.3 -> 88.4% distinct.
R22 clean-fleet: 140 passed, 0 failed of 140. dedup 1910/0.
func_8017D318 (184 ins) + func_80181EE0 (198 ins) both banked, + 6 members swept
(6 per-overlay variants failed — ledger material, not a lever).
THE RECONCILE DIRECTION DEPENDS ON WHERE THE TU'S DECL IS, and picking wrong
CREATES the next error (-> cookbook §138):
- decl ABOVE the splice point -> DELETE the draft's duplicate (§100).
func_8017D318: the TU defines MATRIX_/SVECTOR_8017C290, D_801EA8C0 AND a
`struct PW8017C290` tag above it; I missed the tag on the first pass, so it
took two rounds.
- decl BELOW the splice point -> KEEP a decl in the TU's EXACT shape and cast
at the use (§17a-1 D2). func_80181EE0: I removed its decl assuming the TU
provided one; the TU's `extern int func_80143C74(short *, int);` is at L5082,
~180 lines BELOW the splice at 4901, so the identifier went undeclared.
Grep the TU for the symbol and compare line numbers with the stub line first.
MY OWN §136a VIOLATION, recorded: the blocker-capture filtered the build log for
`error|conflicting|undefined reference` and reported "NO COMPILE ERROR" on a
build that was failing with `redefinition of struct PW8017C290` and
`'func_80143C74' undeclared` — neither phrase matched. A narrow keyword filter is
exactly how a real error goes unseen, which is the thing §136a exists to say.
Widened to keep any line naming a source position.
Fleet 96.21 -> 96.23% fn-count / 93.8 -> 93.9% instr / 88.0 -> 88.3% distinct
(+73 unique fns). R22 clean-fleet: 140 passed, 0 failed of 140. dedup 1910/0.
THE WAVE. Re-ran S10's 17 unbanked targets (26,227 templatable ins) at LOW
concurrency in two batches of ~9 — S10's finding was that 14 of 30 agents were
SERVER-throttled, i.e. the limiter is capacity, not capability. Targets
re-derived against corpus.stubs first (R35): all 17 still live, paths verified.
25 agents, 6.87M tokens, ~2.8h. Claimed 15 MATCH; the whole-binary gate — the
sole arbiter (G3/P9) — banked 13, then family_sweep propagated 65 members across
38 overlays.
HEADLINE: func_8017D174 (793 ins) — the largest single crack of this phase. Its
agent closed two compiler-internal residuals jointly: a §137 allocno-priority tie
between &g.sz0/&g.sz1 (R=7, L=607 vs 606 -> 230/231) that spilled the wrong one
and cost a load-delay nop in BOTH switch arms, and a sched2 rotation in the
outer-loop head block that survived 470+ statement orderings. Fix was four
zero-byte asms: two `"=r"/"0"` re-ties splitting wz's live range, plus two
volatile sliders placed in a DIFFERENT basic block so they lift the live-length
count without perturbing the head schedule.
THE 4 NON-BANKS SPLIT CLEANLY (§136b — none is a wall on one attempt):
- func_8017E2EC (close=20) and func_80186E24 (close=187): honest DIFF verdicts,
real codegen residuals, ledger material.
- func_8017D318 and func_80181EE0: claimed MATCH, gate refused -> the known
match_one->gate gap, which is DECLARATION plumbing (agents cannot run the
gate, so a TU-level conflict is invisible to them). Routed to the reconcile
lane, not retired.
AGENT-REPORTED INDEX GAPS worth acting on (the flywheel closing on itself):
- no symptom key for "schedule rotation at a loop-head block that NO statement
permutation reaches" — the index's nearest line points at §76 regalloc, and
the decisive doc was gcc-2.7.2-map/sched.md, which no scheduling symptom
cross-references.
- §137 is written as a two-compile arithmetic on ONE contender pair; the real
fix here was an N-zero-byte-insn budget that ties only for N in {1,3,4} and
splits the WRONG way for N=2, so a naive "add one slider, add another" walk
silently regresses.
- no key for "gcc hoists a loop-invariant SYMBOL_REF base out of a loop the
target keeps in the `sym(reg)` macro form" (~105 of func_80186E24's 187).
Fleet 96.17 -> 96.21% fn-count / 93.8% instr / 88.0% distinct; dedup 1909 -> 1910
groups, 0 failed, C1 241216/241216. R22 clean-fleet: 140 passed, 0 failed of 140.
The head is now 5/5 classes, 18,545 templatable ins, all banked this session from
a standing start of 0.
func_801466F0 had sat since S6b behind THREE separate blockers, each of which
looked sufficient on its own to explain the failure:
1. Its definition is under a §37/§73 ASM-LABEL ALIAS (`aF801466F0` in C, bound to
the real symbol by `__asm__`), and dedup_propagate.find_site anchored its head
regex on the literal `func_<ADDR>` — structurally blind to the form, returning
None, which every caller reads as "not matched". Now reuses
family_remap._alias_decl_for rather than growing a second matcher (R33).
2. That matcher was itself blind to the WRAPPED (multi-line) declaration — the
§134 shape, third tool. Fixed by matching over the joined text and mapping the
offset back to the decl's FIRST line (extract_unit carries from there).
Regression control: the single-line form still resolves. Fleet census after:
2,768 of 2,768 alias sites resolve, 0 missed.
3. Its record type was a draft-local typedef, so the body failed
compiles_standalone. Lifted Rec801466F0 to src/shared/engine_types.h INSIDE
the include guard (the SESSION-19 double-include note) and switched both the
macro and the exemplar to it — byte-neutral, gate-proven.
Probed on ONE member before the fleet run: byte-identical 9052dc0e first try.
MEASURED, NOT INHERITED (R37): the S6b note frames the alias-regex gap as a CLASS
of missed work. It is ONE function — 91 distinct alias decls fleet-wide, the
per-line matcher resolved 90. Recording it so a future session does not scope a
phase against a class that does not exist.
cookbook §138 extended with the alias-form tool boundary and the three-blocker
story; index regenerated.
Fleet 96.10 -> 96.17% fn-count / 93.7 -> 93.8% instr / 88.0% distinct.
dedup 1908 -> 1909 groups, 0 failed, C1 241078/241078.
R22 clean-fleet: 140 passed, 0 failed of 140.
func_80147364 4,110 x137 definition-side asm-label alias
func_8016BA68 3,886 x134 dedup_extend + the MIRROR decl relax
func_8012F274 3,973 x136 hand-authored macro, source overlay excluded
func_8012A598 3,288 x138 cdecl._mask backscan fix + shared-type switch
func_801466F0 3,288 OPEN the wrapped-alias regex — measured as ONE function
THREE DISTINCT CARRY VARIANTS were hiding in one "CARRY-FIXABLE" bucket, and
only one is a tool bug (-> cookbook §138):
- a MULTI-LINE comment halts the preamble backscan -> fix the tool (cdecl._mask)
- a draft-local `struct Tag {…}` -> switch the exemplar to the SHARED type
- a file-scope `static inline` helper -> hand-author, EXCLUDE the source overlay
The third is the sneakiest: gcc-2.7.2 accepts implicit function declarations, so
the extracted body PASSED compiles_standalone with the helper undeclared and the
miss surfaced only as a whole-binary byte DIFF 137 gates later. Instantiating
that macro in the SOURCE overlay is a duplicate definition (its file-scope helper
is still there), so the shape is `--source-overlay X --binaries <all-but-X>`;
`--binaries` alone removes the source from the scan pool and errors.
TOOL BOUNDARY: once a group's members are DEFINE_func_*() sites, dedup_propagate
cannot extend it (find_site never returns a `def`). dedup_extend is the tool for
an already-macro-ized group — and `dedup_extend --check-only` across ordinary
overlays is a cheap fleet-wide wiring census (measured: exactly 1 group per
overlay, so no hidden backlog).
MEASURED, NOT INHERITED (R37): the S6b note frames _alias_decl_for's single-line
regex as a CLASS of missed work. It is not — 91 asm-label alias decls exist
fleet-wide, the regex matches 90, and the single miss is func_801466F0. Worth
3,288 ins, but a one-function fix. Correcting the expectation so a future session
does not scope against it.
HONEST CORRECTION to commit:1382. That commit's message implies the 42 `(void)`
relaxes unblocked the PROPAGATE remainder. They did NOT: the re-run banked 0/1
in all 134 overlays with the same error, because DEFINE_func_8016BA68 declares
func_80146C3C `(u8*)` — the MIRROR of the EXTEND-lane pair — and my relax only
touched the `(void)` direction.
Root cause is the R37 shape a third time: I bucketed by SYMBOL and stopped. The
lever is set by the (macro-shape, TU-shape) PAIR, and the same symbol conflicts
in BOTH directions across this fleet. One awk over the macro I was ACTUALLY
fixing — which I ran for the EXTEND macros and not for this one — shows the pair
before a 134-build run. §138 amended with the PAIR rule; correction logged in
CURRENT_PHASE.md rather than rewritten out of history.
The 42-decl relax still stands: byte-neutral, R22 140/140, removes a real
conflict class. It just did not do what I predicted.
THIS commit relaxes the 2 remaining `(u8*)` decls (uses are cast; `()` is
compatible with the (void)/()/(u8*) forms the fleet carries and no decl of this
symbol has a default-promotion param). R22 clean-fleet: 140 passed, 0 failed.
ALSO: tools/overlay_src_split.py `_split_macro_body` — the §134 sweep's one real
target, fixed. It carried the identical single-line-only comment test, and it
decides where a macro body's file-scope externs END, so a multi-line comment
truncated the extern set. SIZED FIRST: 38 live lines in engine_core.h macro
bodies hit it today. Now decides on cdecl._mask (one oracle, R33) with the
length-preservation invariant asserted (R32). Proven both directions by a
control: pre-fix it stopped at `/* multi` carrying 1 of 2 externs and treated the
comment as the definition head; post-fix both externs carry and the def head is
correct. Not in the gate path (only o0_subsplit + jr_isolate_all import it).
Diagnosed the 11,147-ins PROPAGATE remainder with one probe, in §138's order:
1. ONE COMMAND, NO BUILD: the originals of BOTH 0x8016BA68 and 0x8012F274 are
sha1-identical across ov_SC07_006 / ov_SC06_025 / ov_SC01_000 / ov_SC01_077 /
ov_SC03_001 -> the registry is sound; the cause is TU context.
2. ONE BUILD in an excluded overlay named it: `conflicting types for
func_80146C3C` — the SAME symbol as the EXTEND lane, same (void)-vs-(u8*)
shape, same one-token lever. The 137 [exclude] lines were one declaration.
Relaxed the remaining 42 `extern void func_80146C3C(void);` in engine_core.h to
`()`. Measured safe BEFORE editing (§138): every fleet decl of the symbol is
`(void)/()/(u8*)/(u8 *a0)` — no default-promotion param anywhere, so gcc-2.7.2's
`()` rule cannot bite — and every use in the header is a no-arg call or already
cast, so it is codegen-neutral. R22 clean-fleet: 140 passed, 0 failed of 140.
TOOL BOUNDARY worth recording: `dedup_propagate` CANNOT finish this one. The 4
SC07 members are now `macro` sites, so `find_site` never returns a `def` and the
auto-source scan errors with "no source overlay has it matched". Extending an
already-macro-ized group is `dedup_extend`'s job. Probe: exactly 1 extendable
group per ordinary overlay — so the fleet has no hidden wiring backlog beyond
this function (a useful negative, R32-shaped).
Also logged: the §134 scanner sweep is sized and has ONE real target —
tools/overlay_src_split.py:345 (_split_macro_body) carries the identical
single-line-only comment test, and it decides where a macro body's file-scope
externs END, so a multi-line comment there silently truncates the extern set.
The other scanners in that file track block-comment state; split_src_region.py
and family_remap.py already handle the multi-line form.
Fleet 96.06 -> 96.10% fn-count / 93.7% instr / 88.0% distinct; dedup 1907 -> 1908
groups, 0 failed, C1 240807/240807. R22 clean-fleet: 140 passed, 0 failed of 140.
func_8012A598 (3,288 templatable ins) was being written off as CARRY-FIXABLE.
It took TWO fixes; either alone leaves it skipped.
1. TOOL (R33) — find_site's preamble backscan. The SESSION-18 fix handled blank,
`//`, and SINGLE-LINE `/* … */` lines, but a MULTI-LINE block comment still
halted the walk: its middle lines start with `*` and its last line ends `*/`
without starting `/*`. So the three externs above the body were dropped and
the body then failed compiles_standalone on now-undeclared data. This is the
§134 multi-line-blindness class — S6b fixed the identical shape three times in
family_remap (D1/D2/D5) and this copy was never reached.
Fixed by deciding skippability on `cdecl._mask` — the project's ONE masking
oracle — instead of on line syntax: it subsumes every comment form at once and
cannot be fooled by a `/*` inside a string, with an R32 assertion on the
length-preservation invariant it rests on. Strictly monotone (it can only
carry MORE preamble), and dedup_propagate is a byte-gate feeder, so a bug here
can fail to bank but never falsely bank.
2. EXEMPLAR — the body also declared a draft-local `struct BigCopy164` tag, which
the tool refuses by design (two macros defining one tag would redefine it in a
single TU). The shared `struct BigCopy` (engine_types.h L312) is the identical
layout and is ALREADY used this exact way at engine_core.h:16158, so switching
the exemplar to it is byte-neutral and drops the alias too.
Probed on ONE member before scaling (R37/S29): byte-identical 9052dc0e first try;
then 138 overlays byte-identical.
PROPAGATE head accounting after this: 7,398 of 18,545 ins banked (func_80147364
4,110 + func_8012A598 3,288). Still open, each with a NAMED cause and none yet
diagnosed against a build: func_8012f274 (3,973, dropped), func_8016ba68 (3,886,
4/138), func_801466f0 (3,288, the S6b D4 wrapped-alias gap).
Drew T