Lîm Tsú-thuàn

reproducible in 0.13.5, and AOT will make bus error. wat code ```wasm (module (type (;0;) (func (result v128 v128 v128 v128 v128 v128 v128 v128 v128))) (func (;0;) (type 0)...

Not sure, with wat as below ```wasm (module (type (;0;) (func (result v128))) (func (;0;) (type 0) (result v128) v128.const i32x4 0x31ade6ad 0xbf869822 0xdb87594b 0x48fd608e v128.const i32x4 0x98b0d628 0xe4357829 0xe540fb45...

Ok, I think I get why, wasmedge 0.13.5 has same output as wasmtime 15.0.1 with original file reported here, output is: ``` 340282366920938463463374607431768211455 340282366920938463463374607431768211455 340282366920938463463374607431768211455 340282366920938463463374607431768211455 340282366920938463463374607431768211455 340282366920938463463374607431768211455 340282366920938463463374607431768211455 340282366920938463463374607431768211455...

It seems before this you need to fix the binding, from my check, the CI failed in a week.

Oops, we don't use merge, try rebase or cherry-pick again.

`f64x2.mul` has no problem, below example shows it's behave normal ```wasm (module (type (;0;) (func (result v128))) (func (;0;) (type 0) (result v128) v128.const i32x4 0xcba8d4ca 0xfcb11f90 0xbcf36ba4 0x7432877d v128.const...

I believe so, they use same foundation in interpreter mode.

And please update the major content of the issue, so contributors will no need to track the whole thread.

Latest wasmedge seems done it without problem ``` ➜ ./tools/wasmedge/wasmedge simd-mul.wasm 340282366920937259259921195292478734080 ➜ wasmtime simd-mul.wasm warning: using `--invoke` with a function that returns values is experimental and may break in...

``` ➜ ./WasmEdge-0.13.4-Darwin/bin/wasmedge simd-add.wasm 340282366920938463463374325956791631870 ➜ ./WasmEdge-0.13.4-Darwin/bin/wasmedge simd-mul.wasm 340282366920938463463374607431768211455 ``` There has bug in 0.13.4, but fixed in latest version, close as complete.