Interpreter: Don't change NaN bits when dividing by 1 (#2958)

It's valid to change NaN bits in that case per the wasm spec, but
if we do so then fuzz testcases will fail on the optimization of

nan:foo / 1 => nan:foo

That is, it is ok to leave the bits as they are, and if we do that then
we are consistent with the simple and valid optimization of removing
a divide by 1.

Found by the fuzzer - looks like on x64 on some float32 NaNs,
the bits will actually change (see the testcase). I've seen this on
two machines consistently, so it's normal apparently.

Disable an old wasm spectest that has been updated in upstream
anyhow, but the new test here is even more strict and verifies
the interpreter literally changes no bits.

1 files changed, 15 insertions, 0 deletions

diff --git a/test/passes/fuzz-exec_O.wast b/test/passes/fuzz-exec_O.wast
index 3d03de714..44bbd7101 100644
--- a/test/passes/fuzz-exec_O.wast
+++ b/test/passes/fuzz-exec_O.wast
@@ -20,4 +20,19 @@
   )
  )
 )
+(module
+ (type $f32_=>_none (func (param f32)))
+ (type $none_=>_i64 (func (result i64)))
+ (import "fuzzing-support" "log-f32" (func $fimport$0 (param f32)))
+ (export "func_113" (func $0))
+ (func $0 (result i64)
+  (call $fimport$0
+   (f32.div
+    (f32.const -nan:0x23017a) ;; div by 1 can be removed, leaving this nan
+    (f32.const 1)             ;; as it is. wasm semantics allow nan bits to
+   )                          ;; change, but the interpreter should not do so,
+  )                           ;; so that it does not fail on that opt.
+  (i64.const 113)
+ )
+)