From 5172df5f0b1c54219e0629accc2fa603236dc0ba Mon Sep 17 00:00:00 2001
From: Drew T <50529377+Druthulu@users.noreply.github.com>
Date: Thu, 3 Sep 2026 10:41:57 -0600
Subject: [PATCH] =?UTF-8?q?fix(build):=20REORDER=5FTUS=20missed=20800c2=5F?=
 =?UTF-8?q?2/800c2=5F3=20=E2=80=94=20$(filter)=20is=20an=20exact=20stem=20?=
 =?UTF-8?q?match?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

`$(filter $*,$(REORDER_TUS))` matches the TU stem EXACTLY, so `800c2` never
covered `800c2_2` or `800c2_3`. Those two TUs went through maspsx while their
siblings went through reorder_passthrough | as -O2 (the §332b island, landed
2026-09-01).

That gap is why func_80062388's `lui at / jr ra / sw a0,lo(at)` was written up
as COMPILER-INEXPRESSIBLE in cookbook §452: a probe (`void f(int v){D=v;}` ->
cc1 -> reorder_passthrough | as -O2) emits exactly that sequence. It was a
build-config gap, not a gcc-2.7.2 define_delay limit. §452 corrected.

Byte-neutrality PROVEN the right way -- gate_main --assert-baseline builds the
committed tree with NO draft substituted:
    BASELINE GREEN — 143dbb89f34491258bbc27810d0a12ec8b43a8dd BYTE-IDENTICAL

This unblocks the 24 SDK-C-REORDER units, four of which were banked as verbatim
assembly on 2026-09-02 off a wall list that predated the fix by one day, with
closeness-0 drafts already in hand.
---
 Makefile | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 7905bef544..5bd3329c8a 100644
--- a/Makefile
+++ b/Makefile
@@ -729,7 +729,13 @@ CC1FLAGS := -quiet -O2 -G0 -mips1 -mcpu=3000 -mgas -msoft-float -fgnu-linker
 # TUs only, swap maspsx for tools/reorder_passthrough.py + `as -O2` — the pipeline
 # tools/oracle_reorder.py proved byte-exact (0 diffs on func_80061FA8 vs 57 on the pinned path).
 # The whole-binary SHA1 gate is the arbiter: if this were wrong the build simply fails.
-REORDER_TUS   := 800c2 800c3
+# The §332b -O2 reorder island. THE STEMS MUST BE LISTED INDIVIDUALLY: `$(filter $*,...)` is an
+# exact match, so `800c2` does NOT cover `800c2_2`/`800c2_3` — those TUs were assembled through
+# maspsx while their siblings went through reorder_passthrough, which is why func_80062388's
+# `lui at / jr ra / sw a0,lo(at)` read as COMPILER-INEXPRESSIBLE (P31 S75): a probe showed cc1 +
+# reorder_passthrough + `as -O2` emits exactly that sequence. It was a build-config gap, not a
+# gcc limit (cookbook §452 corrected).
+REORDER_TUS   := 800c2 800c2_2 800c2_3 800c3
 ASFLAGS_REORDER := -Iinclude -march=r3000 -mtune=r3000 -no-pad-sections -O2 -G0
 
 build/src/%.o: src/%.c