BFM-decomp/cookbook/C0310.md

What I could not verify

From part1:

• func_80181E64 (ov_SC07_006): the note's comparison between a volatile/__asm__ fence spelling (claimed to "materialize the copy but block a later li hoist via the #APP/#NO_APP barrier") and the $0-add RC-12 spelling could not be checked — the banked code (src/ov_SC07_006/ov_SC07_006_jr_8017BEBC.c:4636-4641) uses the plain register s32 zr __asm__("$0"); t = v + zr; form only; no fence spelling exists in the tree to compare against. Only the RC-12 half (already §136d-1) is verified.
• func_800CB9F8 (md_MAIN_019): could not independently verify the specific claim that "a plain copy or a §194-A zero-byte fence did NOT pin" the 5th stack-borne argument's load before call #1 — only the winning volatile spelling is observable in the committed tree; the rejected variants are not preserved.
• func_800CB2E0 (md_MAIN_015): the note's central "switch head duplication" mechanism describes hoisting func_80163408(...)'s result into a named local cmd as the fix — checked against src/md_MAIN_015/md_MAIN_015.c:150-166 and the banked code calls func_80163408(...) as a bare void-context statement, never assigning it to cmd. The described causal mechanism does not match the banked bytes; only the pin-colour/frame-decode portions of this note were verifiable.
• func_800CB1A0 (md_MAIN_019): the harvested note describes an unresolved "near 3... levers exhausted" state with no winning C shape recorded, yet the function is present as real C in the current tree (src/md_MAIN_019/md_MAIN_019.c:129). Whatever ultimately closed the residual is not captured in this note — nothing to verify or promote from it.
• func_8017DFE4 (ov_SC03_011): could not independently confirm from the note alone whether the mid-session "oracle target silently switched to ov_SC03_124's namesake" was a one-time card-metadata glitch or a reproducible harness condition; only that resubmitting the identical C against the (presumably) restored correct target re-confirmed the MATCH.

From part2:

• func_800CB1A0 (md_MAIN_019): the note's claim that the wrong-bank shard specifically belonged to "md_MAIN_028's function at the same VA" could not be independently re-checked — only the current, correct banked body is on disk, not the discarded wrong-bank draft. The underlying caution (validate a replayed shard's instruction count / binary against the target before trusting it) is consistent with the already-documented §238 stale/wrong-body class.
• func_8018271C (ov_SC03_104): the note's "tail-web direction A/B" inversion (pinning $2 to the ADDRESS rather than the value) could not be checked as a generalizable lever — the note itself says this was a per-function judgement call, not a restatable rule, and no counterfactual draft is on disk to compare against.
• func_80182664 (ov_SC06_020): the claimed causal mechanism ("pure pseudo-creation ORDER feeding allocation, not scheduling") is plausible but was not independently traced against gcc-2.7.2 internals in the time available; treated as a restatement of the already-pervasive statement-order/register-class family rather than promoted as new.

From part3:

• func_800CB3AC (md_MAIN_028): the claim that a (void)-prototyped callee decl lets gcc sink a plain store BELOW a later call (vs. an unprototyped K&R decl "forbidding crossing the opaque call") could not be independently confirmed as a distinct mechanism within this review's time budget — a function call is ordinarily treated as clobbering memory regardless of its prototype's arg-count declaration in this compiler, so the causal claim as stated is not obviously sound. The outer if/else layout half of the same candidate IS confirmed as an ordinary case of the already-documented guard-clause triage (§225 addenda 7/8), which only prescribes TRYING early-return, not that it always wins.
• func_8017FCFC (ov_SC04_020): the note describes a "near-4" plateau, not a MATCH, and lists four levers as new. Since this candidate set is defined as byte-gate-BANKED functions, this note is very likely attached to a losing/superseded attempt rather than the actual winning submission for this function — none of its four claimed levers could be checked against a final banked body from this note alone. (Its RC-12 $0-add item would be COVERED by §136d-1/§274 regardless, if it were independently confirmed.)
• func_80181E64 (ov_SC07_006, de, 9 calls): same class as above — ends at "near 11/103", no MATCH declared; could not verify against banked bytes.
• func_80181B04 (ov_SC01_009, 1st entry, 1 call): ends unresolved; superseded within this same batch by a second entry for the identical function (4 calls) that does reach MATCH 46/46 with a different, resolved lever. The unresolved first entry's specific claims were not independently checked since a resolved account for the same function exists.

From part4:

• func_801EE838 (md_SC05_025): the note's specific claim that the WAR order (store-before-load on the dead-parameter register) "falls out of the statement order for free" once the register is pinned was not independently re-derived from RTL/compiler internals — accepted on the strength of the already-general §215 pin-economy family and the note's own oracle-verified MATCH, not independently re-probed with a counterfactual.
• func_8017D9A4 (ov_SC06_018): five itemised sub-claims (missing 2nd call argument, dying-temp naming, store-before-compare reload via cse-fold, sra-positioning, register-coloring via a fresh iVar5) were judged collectively as within already-covered families from the note's own prose; none was individually re-derived against the .s byte-by-byte within this review's time budget.
• func_80185ABC (ov_SC03_102): did not independently re-run a counterfactual (u8 *p declared before s32 i) against the actual banked bytes to confirm the mirrored-allocation claim; accepted on the strength of §31's already-established, closely analogous RC-1/RC-2/RC-3 law.

From part5:

• func_800CB0D8 (md_MAIN_028): the note's headline claim — that DECLARATOR-INITIALIZER pin declaration order (as opposed to statement-level pin assignment) controls prologue expansion order for two hard-reg-pinned values — was not independently re-derived from RTL and directly conflicts with the existing, rigorously A/B'd §164-63 (which found the sw/move pair order for two hard-reg-pinned ENTRY values invariant to declaration order, including a reversed-declaration-order control, and moved only by an interposed zero-byte asm). The candidate's scenario differs in one respect §164-63 did not test — one of the two pins is initialized from a GLOBAL ADDRESS (la-class materialization) rather than a second incoming argument register — so the mechanisms are not provably identical, but the claim as stated ("declaration order controls expansion order") is not safe to promote without a reversed-declaration-order control of this exact case, which was not run here.
• func_801916BC (df) / func_8017F024 (df): both are exact duplicates (same function, same claim) of instances already reviewed and verdicted within this same 271-candidate batch from wave dd — flagged here rather than independently re-litigated, since a second write-up would just restate the first reviewer's finding.

From part6:

• func_80182F5C (ov_SC04_000): the note's specific claim about why an earlier draft misread which addiu fed the sh vs the bne (a forensic .s-reading error, not a C-spelling defect) could not be independently reconstructed from the rejected draft (only the final banked text is on disk); the final banked constants (6/6 stored, mode==2 tested) are confirmed correct against src/ov_SC04_000/*.c and the target .s, but the counterfactual "wrong" reading is not checkable.
• func_8017D12C (ov_SC06_032): the note's claim that two decl-text spellings (A: extern void func_8002931C(s32 a0); plain call; B: extern void func_8002931C(void); cast call) compile to byte-identical standalone asm, and that ONLY decl-text choice (not some other unlisted difference between the sessions) was the actual whole-binary-gate blocker, could not be independently confirmed — only the final, third, banked form is on disk. See also the harness-defect flag below.
• func_80184CB0 (ov_SC03_097): did not independently re-derive gcc-2.7.2's chained-assignment (sp30[0] = sp30[1] = 0;) innermost-RHS-first store order from source; accepted on the strength of the note's own §263 citation plus the visible 2-instruction store-order match in the final banked text.

---