Wasmi returns unexpected NaN bit pattern

[erxiaozhou]

Description

Current State

0x0 0x0 0x0 0x2f 0x0 0x0 0xf0 0xff

Expected

........ 0xf8 0xff (The most significant bit of payload is 1)

Environment

• Code Version: git commit id fdc136f
• Hardware Architecture: x86_64
• Operating system: Ubuntu 20.04

Steps to Reproduce

wasmi.zip

1. build the wasmi
2. run the test case by wasmi <test_case_name> to_test

[Robbepop]

wasmtime run wasmi_nan.wasm --invoke to_test prints NaN and wasmi_cli wasmi_nan.wasm to_test prints NaN as well. What else do you expect exactly? There is no differentiation between +NaN and -NaN in case you mean that.

[erxiaozhou]

wasmtime run wasmi_nan.wasm --invoke to_test prints NaN and wasmi_cli wasmi_nan.wasm to_test prints NaN as well. What else do you expect exactly? There is no differentiation between +NaN and -NaN in case you mean that.

Thank you for your reply. The output is NaN is as expeced. However, according to the specification https://webassembly.github.io/spec/core/exec/numerics.html#floating-point-operations, in this example, for the value on the stack, the most significant bit of payload is supposed to be 1. It means the highest 13 bits are 0111 1111 1111 1 or 1111 1111 1111 1 . In this example. The highest 13 bit of the value on the stack is 1111 1111 1111 1.

Thank you!

[Robbepop]

With respect to Wasm spec testsuite compliance for NaN values in wasmi I found that wasmi's current spec testsuite is not 100% correct on the semantics of NaN value checking compared to what Wasmtime does here: https://github.com/bytecodealliance/wasmtime/blob/main/crates/wast/src/core.rs#L106

In contrast, wasmi simply evaluates .is_nan(). I am sure we can find and fix those NaN sign bit errors by improving the Wasm spec testsuite in this regard.

[Robbepop]

@erxiaozhou I just re-ran the above test with Wasmi v0.38.0 and got the following result:

Original output of old Wasmi version from bug report: 00 00 00 2F 00 00 F0 FF
Expected output: 00 00 00 2F 00 00 F8 FF

% wasmi_cli 04-original.wasm
nan:0x7FF8000000000039

I guess the bits have to be swapped: 39 00 00 00 00 00 F8 7F
So while the end now seems to be correct we have the 39 byte at the start and are still missing the 2F byte in the middle ...

Wasmtime funnily just returns a NaN without further description:

% wasmtime 04-original.wasm
NaN