Wasmer reports compilation error from inconsistent nan canonicalization
Describe the bug
I generated a test case and executed it with different runtimes. Other runtimes like wasmtime, wamr, wasmedge, and wasmer's cranelift backend output a list of numbers. But, wasmer's llvm backend reports a compile error resulting from two different nan canonicalizations.
$> wasmer -vV; rustc -vV
wasmer 6.0.0 (9ef4e4e 2025-06-27)
binary: wasmer-cli
commit-hash: 9ef4e4e7382b53c06aaadf4aa864b726c4851dc3
commit-date: 2025-06-27
host: x86_64-unknown-linux-gnu
runtimes: singlepass, cranelift, llvm
rustc 1.88.0 (6b00bc388 2025-06-23)
binary: rustc
commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
commit-date: 2025-06-23
host: x86_64-unknown-linux-gnu
release: 1.88.0
LLVM version: 20.1.5
Steps to reproduce
Test case: Removed the larger test case in favor of the reduced version mentioned in the comments.
Steps to reproduce:
- Convert wat to wasm.
- Run:
wasmer run --enable-simd --enable-threads --enable-verifier --enable-reference-types --enable-multi-value --enable-bulk-memory --enable-relaxed-simd --enable-extended-const --llvm shrunken_test1436702.wasm --invoke main
Expected behavior
Should output 0 0 0 0 0 0 0 0
Actual behavior
Outputs:
error: Unable to compile "shrunken_test1436702.wasm"
╰─▶ 1: compile error: Codegen("Can't produce bitwise or of two different states if there are two different kinds of nan canonicalizations at the same time")
Additional context
I tested on Ubuntu 22.04 OS and x86_64 CPU. Can you please confirm? Thanks in advance.
I think the other runtimes would pick one kind of nan canonicalization and output the numbers. But, wasmer reports a compilation error. What do you think, @syrusakbary?
Here is a reduced test case that produces the same error:
(module
(func (;0;)
v128.const f32x4 nan:0x100000 nan:0x200000 nan:0x300000 nan:0x400000
f32x4.trunc
f64x2.ceil
drop
)
)
The LLVM backend seems to apply one NaN canonicalization to f32-based SIMD instructions and another for f64-based SIMD instructions.