3d8e2ced2e
PPCBUG-053: bcx and bclrx tested `ctx.ctr != 0` against the full 64-bit register, but the Xbox 360 ABI runs CTR as a 32-bit counter (canary explicitly truncates: `f.Truncate(ctr, INT32_TYPE)`). When upstream 64-bit GPR pollution flowed through `mtspr CTR, rN`, the upper 32 bits stayed non-zero forever; bdnz then looped past the intended 32-bit zero point because the 64-bit comparison still saw the high bits. PPCBUG-054: `mtspr CTR` writeback wrote the full 64-bit GPR value, acting as a firewall gap that fed PPCBUG-053. Defensive truncation prevents CTR from ever acquiring non-zero upper 32 bits independently of the GPR-pollution source. Fixes: - interpreter.rs:849, 879: ctr_ok now uses `(ctx.ctr as u32) != 0` - interpreter.rs:1523: mtspr CTR writes `val as u32 as u64` Tests: - bcx_bdnz_uses_32bit_ctr_compare: bdnz with CTR=0x0000_0001_0000_0001 decrements to 0x0000_0001_0000_0000 and exits (low 32 bits = 0). - bclrx_uses_32bit_ctr_compare: same coverage for bdnzlr. - mtspr_ctr_truncates_to_32_bits: gpr=0xFFFF_FFFF_8000_0001 → ctr=0x8000_0001. Coupled fix per the audit: PPCBUG-053 and PPCBUG-054 land together because either alone is necessary-but-not-sufficient — the truncation prevents new pollution, the 32-bit compare protects against any pollution that slipped in via routes other than mtspr (e.g. mfctr-mtctr roundtrips). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>