What causes "unsupported location" in wasmerio/wasmer?

Use the Cranelift backend instead of singlepass on RISC-V

unsupported location

Error message

unsupported location

What it means

`location_to_reg` in the RISC-V machine backend converts a compile-time `Location` (GPR/FPR/stack slot/etc.) to a register; the `_ => todo!("unsupported location")` arm panics when it receives a location kind the RISC-V backend cannot materialize (e.g. certain immediate or pseudo locations). Called from FPR conversion and relaxed binop/atomic/cmp emission helpers.

Source

Thrown at lib/compiler-singlepass/src/machine_riscv.rs:201

                if imm == 0 {
                    Ok(Location::GPR(GPR::XZero))
                } else if allow_imm.compatible_imm(imm) {
                    Ok(src)
                } else {
                    let tmp = if let Some(wanted) = wanted {
                        wanted
                    } else {
                        let tmp = self.acquire_temp_gpr().ok_or_else(|| {
                            CompileError::Codegen("singlepass cannot acquire temp gpr".to_owned())
                        })?;
                        temps.push(tmp);
                        tmp
                    };
                    self.assembler.emit_mov_imm(Location::GPR(tmp), imm as _)?;
                    Ok(Location::GPR(tmp))
                }
            }
            _ => todo!("unsupported location"),
        }
    }

    fn location_to_fpr(
        &mut self,
        sz: Size,
        src: Location,
        temps: &mut Vec<FPR>,
        allow_imm: ImmType,
        read_val: bool,
    ) -> Result<Location, CompileError> {
        match src {
            Location::SIMD(_) => Ok(src),
            Location::GPR(_) => {
                let tmp = self.acquire_temp_simd().ok_or_else(|| {
                    CompileError::Codegen("singlepass cannot acquire temp fpr".to_owned())
                })?;
                temps.push(tmp);

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

Use the Cranelift backend instead of singlepass on RISC-V
Adjust/restructure the wasm module (e.g. avoid atomic ops) to steer clear of the unsupported code path
Upgrade wasmtime so RISC-V location handling covers the missing Location variants
Capture a backtrace to identify which emission helper received the bad location and file an upstream issue

Example fix

// before: singlepass on riscv with such patterns panics
config.strategy(Strategy::Winch);
// after: use the mature backend
config.strategy(Strategy::Cranelift);

Defensive patterns

Strategy: fallback

Validate before calling

// Prefer a backend with complete RISC-V location handling before compiling.
let mut config = Config::new();
if cfg!(target_arch = "riscv64") {
    config.strategy(wasmtime::Strategy::Cranelift);
}
let engine = Engine::new(&config)?;

Try / catch

let compiled = std::panic::catch_unwind(|| Module::new(&engine, &wasm_bytes));
if compiled.is_err() {
    // singlepass riscv hit an unsupported Location; retry with Cranelift
    let mut cfg = Config::new();
    cfg.strategy(Strategy::Cranelift);
    Module::new(&Engine::new(&cfg)?, &wasm_bytes)?;
}

Prevention

Use Cranelift for workloads using atomics or complex operand patterns on RISC-V
Keep wasmtime updated; RISC-V singlepass is incomplete
Add compile smoke tests per platform to catch panics before production

When it happens

Trigger: Singlepass RISC-V code generation where an operand location is not a GPR/FPR the backend expects — e.g. an immediate or unsupported location passed to emit_relaxed_binop / emit_relaxed_binop3 / emit_relaxed_atomic_binop3 / emit_relaxed_atomic_cmpxchg / emit_relaxed_cmp via location_to_reg or location_to_fpr (machine_riscv.rs:201).

Common situations: Compiling wasm with instruction patterns the incomplete RISC-V singlepass backend hasn't modeled (atomics, unusual operand orders), exposing unhandled Location variants.

Related errors

AI-assisted analysis of wasmerio/wasmer@8c4b9ee9d3 (2026-09-01). Data as JSON: /api/errors/cc9205fcf1a13715. Report an issue: GitHub.