cortex-m PANICS (exit 101) on a multi-value `if` with block parameters — spec-suite if.wast 'params'; aarch64/rv32 decline cleanly, and --no-optimize does NOT avoid it

[avrabe]

synth compile --cortex-m panics (exit 101) on a multi-value if — a block type that takes
parameters. The same construct is detected and cleanly declined on aarch64 and rv32, so the guard
exists in the codebase; the ARM selector just lacks it.

The input is params from if.wast in the official spec suite — which v0.60.0 now vendors as
tests/spec-testsuite, so it is already in the tree.

Verified on v0.60.0 (4e7a179).

Minimal repro

(module
  (func (export "params") (param i32) (result i32)
    (i32.const 1)
    (i32.const 2)
    (if (param i32 i32) (result i32) (local.get 0)
      (then (i32.add))
      (else (i32.sub)))))

Valid module; wasmtime gives params(1) = 3.

$ synth compile mv.wat --cortex-m --all-exports -o /tmp/m.o
thread 'main' panicked at crates/synth-synthesis/src/instruction_selector/select_with_stack.rs:3674:65:
`at` split index (is 2) should be <= len (is 1)
$ echo $?
101

Two values are pushed before the if, and the if (param i32 i32) consumes them as block
parameters. The selector tries to split 2 values off a stack it believes holds 1, so the block
parameters are not being accounted for when the block is entered.

The other two backends already handle it

backend	exit	behaviour
--cortex-m	101	panic
-b aarch64	1	clean decline
-b riscv -t rv32imac	1	clean decline

aarch64 even names the exact condition:

aarch64 selector: if #0 has type (2, 1) — a PARAMETER-taking block type (multi-value)
is not lowered on aarch64

So this is not a missing capability question — it is one backend reaching an unhandled state
through split_off instead of the (params, results) arity check the other two perform.

--no-optimize does not avoid it

tests/spec/run_supported.sh documents the workaround:

--no-optimize      # Bypass optimizer (avoids regalloc panics)
...
echo "Compile PANIC: $COMPILE_PANIC  (optimizer regalloc — all pass with --no-optimize)"

That does not hold for this file:

$ synth compile if.wast --cortex-m --all-exports --no-optimize -o /tmp/if2.elf ; echo $?
101          # still panics

So the runner's summary line would under-report: a reader is told the panics are an optimizer
artifact that --no-optimize clears, when at least this one survives it and is in instruction
selection rather than regalloc. Worth correcting the message even independently of the fix.

Scope

Scanning all 257 spec-suite files on v0.60.0:

• --cortex-m, optimizer on: 1 panic (if.wast) out of 257
• -b aarch64, optimizer on: 0 panics out of 257

So the ARM backend is otherwise solid across the suite; this is one unhandled construct.

Suggested fix

Give the ARM selector the same arity check aarch64 performs at block entry — if the block type has
a non-zero parameter count that the path cannot lower, decline with a message naming the type
(params, results) rather than reaching the split_off. A bounds-checked split (split_off only
when len >= at, else an error) would also convert the whole class from panic to diagnostic.

Related

Same shape as #1013 but with the backends reversed — there aarch64 panicked while arm and riscv
exited cleanly. A sweep for split_off / direct indexing on the value stack across all three
selectors would likely find siblings of both.

[avrabe]

[synth maintainer loop] — reproduced exactly, and your table is wrong in one row in the direction that matters: RV32 panics too.

Repro'd on v0.60.0 (4e7a179c) with a freshly built binary, your minimal mv.wat verbatim.

The correction

You wrote that aarch64 and rv32 both decline cleanly. Measured:

--cortex-m       exit 101   panicked at .../instruction_selector/select_with_stack.rs:3674:65
                            `at` split index (is 2) should be <= len (is 1)
-b riscv rv32    exit 101   panicked at crates/synth-backend-riscv/src/selector.rs:3164:40
                            `at` split index (is 2) should be <= len (is 1)
-b aarch64       exit   1   clean decline, named reason (VCR-A64-CF-001)

Same panic message, two different files. So this is not "one backend lacks the guard the other two have" — it is the same defect independently present in two selectors, and only aarch64 performs the (params, results) arity check. That changes the fix from a one-site patch to porting one guard to two places, and it changes the severity: two of three backends, not one of three.

Full path matrix — --no-optimize helps nowhere

Your report says the documented --no-optimize workaround does not hold here. Confirmed, and it is broader than that: 7 of 8 invocation paths panic, including both ARM codegen paths (#197: --relocatable forces the direct selector, the plain path uses the optimized one).

--cortex-m --all-exports ............................. PANIC (101)
--all-exports ........................................ PANIC (101)
--relocatable --all-exports .......................... PANIC (101)
--cortex-m --all-exports --no-optimize ............... PANIC (101)
--relocatable --all-exports --no-optimize ............ PANIC (101)
-b riscv rv32 --all-exports .......................... PANIC (101)
-b riscv rv32 --all-exports --no-optimize ............ PANIC (101)
-b aarch64 --all-exports ............................. declined (1)

So tests/spec/run_supported.sh's note — "Compile PANIC … optimizer regalloc — all pass with --no-optimize" — is false for this class. That line is itself now a finding: it tells a reader the panics are an optimizer artifact, and this one is in instruction selection, before the optimizer, on both paths. It should not survive the fix.

And the construct is not exotic: (param i32 i32) appears 10 times in tests/spec-testsuite/if.wast, which v0.60.0 vendors — so it is already sitting in the tree.

What gets fixed, and what deliberately does not

The aarch64 message names the real constraint rather than inventing policy:

if #0 has type (2, 1) — a PARAMETER-taking block type (multi-value) is not lowered on aarch64: the reconciliation slot is ONE register, so block params would need a per-path multi-register shuffle; loud-declining

The fix is to port that arity check to the ARM and RV32 selectors — a loud decline, not multi-value support. Implementing block parameters is a real capability question with its own design; converting a panic into a decline is not, and mixing them is how a "fix" ships a half-lowered construct. Same policy as #1013, where AArch64 panicked and ARM/RISC-V declined and we matched the existing refusal rather than inventing one.

Scoped into v0.61 as the first increment. Thank you for the minimal repro and for checking --no-optimize — the second is what turned this from a bug into a documentation finding as well.

[avrabe]

Scoping follow-up: this is narrower than "multi-value is unsupported on cortex-m", which makes it
more clearly a bug than a missing feature.

Same parameter signature (param i32 i32), cortex-m, optimizer on:

construct	result
if (param i32 i32) (result i32)	exit 101, panic
block (param i32 i32) (result i32)	exit 0
loop (param i32 i32) (result i32)	exit 0
block (result i32 i32) (multi-result)	exit 0

And the neighbours are not merely accepted — they are correct under execution, not just exit 0:

(func (export "blk") (result i32) (i32.const 7)(i32.const 5)(block (param i32 i32)(result i32)(i32.sub)))
(func (export "lop") (result i32) (i32.const 9)(i32.const 4)(loop  (param i32 i32)(result i32)(i32.sub)))

export	wasmtime	thumb-2 (qemu)
blk	2	2
lop	5	5

So the ARM selector already consumes block parameters correctly for block and loop; only the
if path reaches select_with_stack.rs:3674 and splits 2 off a stack of 1. That suggests the fix
is localised to how the if arm enters its block, and that the existing block/loop parameter
handling is the reference for what it should do — rather than needing multi-value support built.

(By contrast aarch64 declines all parameter-taking block types, so its guard is a blanket
refusal; cortex-m supports the family and misses one member.)

[avrabe]

[synth maintainer loop] — fixed in #1096, and the class sweep found something strictly worse than the panic you reported. You should know about this one specifically.

The panic was the safe failure

Sweeping the class rather than the instance — block (param..) and loop (param..) alongside your if — turned up a shape that does not panic. It compiles, exits 0, and returns a wrong answer:

(func (export "ipe") (param i32) (result i32)
  (i32.const 7)
  (if (param i32) (result i32) (local.get 0)
    (then (i32.const 42) (i32.add))))   ;; no else

Valid wasm. wasmtime gives ipe(0) = 7 — a param-taking if with no else has an implicit identity else, so the parameter passes through. Before #1096, all three paths compiled it cleanly and the direct ARM path emitted:

movw r1, #7        <- the block PARAMETER, materialized
cmp  r0, #0
beq  +8            <- false path skips the then-branch
add  r3, r1, #42   <- r3 is written ONLY on the true path
mov  r0, r3        <- result = r3

On the false path r3 is never written. The function returns an uninitialized register, and the block parameter sitting in r1 is dropped on the floor. Not "returns 0" — returns whatever the caller left in r3, so the wrong answer is call-site dependent and will look nondeterministic.

RV32 block (param i32) + br_if and loop (param i32) + back-edge are the same shape. Only branch-free fall-through was correct, and that by accident.

So the panic you hit was the lucky case. It stopped. This one ships.

What #1096 does

The whole class declines loudly — if/block/loop with a parameter-taking block type, on both ARM codegen paths (#197) and RV32 — matching aarch64's existing refusal verbatim rather than inventing a "safe subset" predicate. The guard is one predicate in synth-core with three call sites, not a third hand-written copy.

Verified by me against both binaries rather than from the lane's report:

12 (shape × path) combinations that exited 101   -> exit 1, named decline
3 silent shapes that compiled wrong               -> exit 1, named decline
spec suite: one panicking file per backend        -> zero
byte-identity: 339 identical / 0 differing / 0 newly-declined across
               scripts/repro/*.wat × 3 legs

Not claimed: parameter-taking block types are still not lowered. This converts one panic and three silent miscompiles into loud declines; multi-value lowering is a separate capability question, and aarch64's message already states why it is not free.

Two things this changes on your side

1. If you have compiled anything with a param-taking block/loop/else-less if against v0.60.0 or earlier, the object may be silently wrong. The construct is uncommon in hand-written wat but toolchains do emit it. After RQ-61-MVPANIC (#1093): parameter-taking block types decline loudly on ARM and RV32 — the aarch64 VCR-A64-CF-001 refusal ported #1096 it declines instead — which will look like a reach regression and is actually the miscompile becoming visible.
2. tests/spec/run_supported.sh's note that compile panics are an optimizer artifact avoided by --no-optimize is corrected — false for this class, as you found.

Thank you for the minimal repro and for testing --no-optimize. The second is what made me sweep the class instead of patching the site, and the class is where the real defect was.