Repository navigation
nightly-2025-02-18 wasm-opt cannot process resulting binary #137315
Description
I bisected by hand and at nightly-2025-02-18 wasm-opt started giving errors like this:
...
[wasm-validator error in function 2590] unexpected false: Bulk memory operations require bulk memory [--enable-bulk-memory], on
(memory.copy
(local.get $0)
(i32.add
(local.get $4)
(i32.const 8)
)
(i32.const 40)
)
[wasm-validator error in function 2621] unexpected false: Bulk memory operations require bulk memory [--enable-bulk-memory], on
(memory.copy
(i32.add
(local.get $2)
(i32.shl
(local.get $8)
(i32.const 2)
)
)
(i32.add
(local.get $2)
(i32.shl
(local.get $0)
(i32.const 2)
)
)
(local.get $5)
)
...
It asks for --enable-bulk-memory, if give it to it, other errors reveal (this is the whole output):
> wasm-opt -Oz project.wasm -o new.wasm --enable-bulk-memory
[wasm-validator error in function 520] unexpected false: all used features should be allowed, on
(i32.trunc_sat_f32_s
(f32.mul
(local.get $13)
(f32.const 20)
)
)
[wasm-validator error in function 520] unexpected false: all used features should be allowed, on
(i32.trunc_sat_f32_u
(local.tee $13
(f32.add
(local.get $13)
(f32.const 60)
)
)
)
[wasm-validator error in function 1103] unexpected false: all used features should be allowed, on
(i32.trunc_sat_f64_u
(local.tee $4
(call $fimport$187
(i32.load
(i32.load
(local.get $1)
)
)
(i32.load offset=12
(local.get $2)
)
)
)
)
[wasm-validator error in function 1120] unexpected false: all used features should be allowed, on
(i64.trunc_sat_f64_s
(local.get $4)
)
[wasm-validator error in function 1908] unexpected false: all used features should be allowed, on
(i64.trunc_sat_f64_u
(local.get $9)
)
Fatal: error validating input
For wasm-opt I tried versions form 116 to 120, all failed.
I am compiling web application with dioxus, it uses wasm-bindgen.
Activity
saethlin commentedon Feb 20, 2025
Can you share a reproducer?
Can you bisect using cargo-bisect-rustc to find the relevant PR?
nikic commentedon Feb 20, 2025
This is due to the LLVM 20 upgrade, which enables bulk-memory and nontrapping-fptoint by default. Need to update https://doc.rust-lang.org/rustc/platform-support/wasm32-unknown-unknown.html#enabled-webassembly-features.
cc @alexcrichton
12 remaining items
Rollup merge of rust-lang#137322 - alexcrichton:update-wasm-docs, r=j…
Rollup merge of rust-lang#137322 - alexcrichton:update-wasm-docs, r=j…
eric-seppanen commentedon Feb 21, 2025
A lot of downstream tools (e.g.
trunk) call out towasm-opt, and it causes a lot of downstream build breakage when new wasm features get turned on. The error messages are uninformative and it's not always obvious what the fix is.So far the discussion here hasn't led to a clear way forward. It would be nice if
wasm-optweren't so critical to the rust-webassembly ecosystem, but in the meantime it seems like this should be called out in the release notes so people aren't surprised by the breakage.eric-seppanen commentedon Feb 21, 2025
It would be very helpful if someone with deep webassembly knowledge could weigh in on trunk-rs/trunk#904 .
Would any of these options be the recommended way forward? Should trunk enable all the latest things by default as soon as llvm/rustc does?
Unrolled build for rust-lang#137322
alexcrichton commentedon Feb 21, 2025
@eric-seppanen have you reached out to the
wasm-opt/binaryen folks about this? I suspect they'd be accomodating to the suggestion to enable these proposals by default to match LLVMeric-seppanen commentedon Feb 21, 2025
@alexcrichton
I don't really understand what request should be made. I'm not terribly familiar with the webassembly features, and I'm not a trunk maintainer. What would it mean to say "enable these proposals by default to match LLVM"? Does that mean that each wasm-opt release has a set of defaults that matches a particular llvm version? Or that it should inspect the incoming binaries and somehow determine which set of features to enable for its output? Is this problem specific to rust, or do I need to understand how other languages handle this issue?
alexcrichton commentedon Feb 21, 2025
I'd recommend making a request that the default set of enabled features in binaryen either be (a) proposals that are stage 4+ or (b) proposals that are on-by-default in LLVM. In wasmtime/wasm-tools we do (a) and find that it works well for our use cases, but binaryen might have other use cases as well.
In my mind if binaryen has good reason for not enabling a feature by default then that should be a factor in a decision to enable something in LLVM by default. Often though I find that things aren't on-by-default because it's just forgotten about.
fix(`wasm-opt`): add `--enable-bulk-memory` flag
test: add benchmarks (#21)
Conditionally apply wasm-opt bulk-memory flags for LLVM 20+ toolchains
Conditionally apply wasm-opt bulk-memory flags for LLVM 20+ toolchains
Add wasm opt flags (#101)