WAMR `iwasm` interpreter produces incorrect output on SIMD WebAssembly module

[khagankhan]

Subject of the issue

WAMR simple interpreter iwasm produces a different result from other runtimes most likely because of SIMD instructions.

Test case

discrepancy.wat.txt

discrepancy.wasm.txt

Please remove .txt extesnions when running the WASM modules.

Your environment

• uname -a: x86_64
• lsb_release -a: Ubuntu 22.04.5 LTS
• iwasm --versions: iwasm 2.2.0
• Wamr built:

cd /path/to/wasm-micro-runtime/product-mini/platforms/linux/
mkdir build && cd build
cmake -DBUILD_SHARED_LIBS=ON ..
make -j

Steps to reproduce

Please download the discrepancy.wat.txt and discrepancy.wasm.txt files. Remove .txt extensions and run it with iwasm:

wasm-micro-runtime/product-mini/platforms/linux/build/iwasm -f _main discrepancy.wasm

Expected behavior

iwasm is supposed to produce value zero (0) as _main return like other runtimes:

wasmtime run --invoke _main discrepancy.wasm
warning: using `--invoke` with a function that returns values is experimental and may break in the future
0

Actual behavior

iwasm differs from other runtimes:

CRC mismatch detected! Wasmer: bf56788d, WABT: bf56788d, Wasmtime: bf56788d, WAMR: 9379f56d, WasmEdge: bf56788d

I reduced the test case and removed the host functions that I have used for differential testing. And I think it stems from SIMD instructions. When you run discrepancy.wasm iwasm will produce 1 instead of 0:

wasm-micro-runtime/product-mini/platforms/linux/build/iwasm -f _main discrepancy.wasm
0x1:i32

Despite shrinking the test case using wasm-tools and manually, the best I got was 200 lines. However, most functions can be easily inlined and unreachable ones may be removed. Please tell me if more info is needed.

Extra Info

Wasmoi fuzzer, an Xsmith-based fuzzer produced the snippet of code that found the issue. https://www.flux.utah.edu/project/xsmith

[lum1n0us]

@loganek @jammar1 Would you mind investigating this bug? It is reproducible.

[jammar1]

Yes, will do.

[jammar1]

@khagankhan

Thanks a lot for finding this, could you try with this patch and see if that fixes the issue?

diff --git a/core/iwasm/interpreter/wasm_interp_fast.c b/core/iwasm/interpreter/wasm_interp_fast.c
index 21554953d0..bd7621c507 100644
--- a/core/iwasm/interpreter/wasm_interp_fast.c
+++ b/core/iwasm/interpreter/wasm_interp_fast.c
@@ -1053,6 +1053,11 @@ copy_stack_values(WASMModuleInstance *module, uint32 *frame_lp, uint32 arity,
                         frame_lp + dst_offsets[0],                          \
                         GET_I64_FROM_ADDR(frame_lp + src_offsets[0]));      \
                 }                                                           \
+                else if (cells[0] == 4) {                                   \
+                    PUT_V128_TO_ADDR(                                       \
+                        frame_lp + dst_offsets[0],                          \
+                        GET_V128_FROM_ADDR(frame_lp + src_offsets[0]));     \
+                }                                                           \
             }                                                               \
             else {                                                          \
                 if (!copy_stack_values(module, frame_lp, arity, total_cell, \

Thanks

[khagankhan]

Hi! Of course! Thank you for working on that. It produces the right answer now:

wasm-micro-runtime/product-mini/platforms/linux/build$ ./iwasm -f _main discrepancy.wasm 
0x0:i32

Could you please explain the root cause and provide the minimum reduced code if possible?

[jammar1]

Raised #4203. I didn't reduce any of the code you provided. I commented out function calls / hard coded return values until I found the function that caused the discrepancy.

I think any function that returns a V128 + returns via br would have hit this - bit surprised none of the SIMD spec tests found this.

e.g

(module
  (export "_main" (func $main))
  (func $helper (result v128)
    v128.const i32x4 0x0000000a 0x0000000a 0x0000000a 0x0000000a
    v128.const i32x4 0x0000000a 0x0000000a 0x0000000a 0x0000000a
    i32x4.add
    br 0
  )
  
  (func $main (result i32)
    call $helper
    i32x4.extract_lane 0
  )
)