-
Notifications
You must be signed in to change notification settings - Fork 623
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Different output when running a same binary #2832
Comments
Hi, yes, I checked wasmtime-15.0.0 which was released in 2023-11-20., it reports "out of bounds memory access", but in the recent dev release, it doesn't throw exception. Not sure why. |
bytecodealliance/wasmtime#7558 (comment) I haven't come across any issues with Wasmer yet, and I think Wasmer is probably correct. |
@wenyongh Have you found the reason of this issue? |
@XinyuShe I found that the outs of (func $3 (result v128 v128 v128 v128)
(local $0 v128)
v128.const i32x4 0xbfe4b646 0xee2ae7a5 0x49ff9c4c 0x10fd4f0b
local.set $0
nop
local.get $0
i32x4.trunc_sat_f64x2_u_zero
local.set $0
local.get $0
i32.const 756
i16x8.replace_lane 0
local.get $0
f32x4.gt => the result is `0xffffffff 0x00000000 0x00000000 0x00000000`
v128.const i32x4 0xaad2899f 0x11c60963 0x34076b3e 0x18b611a6
f32x4.max => for wamr and wasmedge, the output is `0xffffffff 0x11c60963 0x34076b3e 0x18b611a6`
for wasmtime and wasmer, the output is `0xffc00000 0x11c60963 0x34076b3e 0x18b611a6` And for wamr and wasmedge, it eventually causes the below opcode to throw OOB exception: block $block
local.get $0
i32x4.extract_lane 0
v128.load32x2_u offset=6522 align=1 => OOB was thrown for wamr and wasmedge
local.tee $0
local.get $0
i32x4.extend_high_i16x8_s I think it is also same as the issue of NaN normalization, for wasmtime and wasmer, |
I used the AOT mode of different runtimes to run randomly generated wasm binaries, and the output from wamr and wasmedge are different from the others.
filea5770.zip
wamr and wasmedge in AOT
wamr in JIT
wasmtime and wasmer in AOT
wasmtime and wasmer in JIT
runtimes before September
Because when I used older versions of the four runtimes from before September to run it, I encountered the situation shown in the figure below. I don't think this is caused by the min and max instructions, but rather by some other bug.
The text was updated successfully, but these errors were encountered: