[wasm][fuzzer] Check for nondeterminism in all fuzzers

The "wasm fuzzer" and "wasm async fuzzer" use the
{InterpretAndExecuteModule} function, which did not check for possible
nondeterminism in the interpreter yet. This can lead to wrong reports
of mismatches, or in endless loops being executed in compiled code which
was not executed in the interpreter.

This CL adds the check for nondeterminism in that function, and adds a
TODO to merge the two very similar methods.

R=ahaas@chromium.org

Bug: chromium:1112099, chromium:1113681
Change-Id: I80b01d4c53d04f0632807fa852147dc9fb8075ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346280
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69324}

test/fuzzer/wasm-fuzzer-common.cc

@@ -50,6 +50,17 @@ void InterpretAndExecuteModule(i::Isolate* isolate,
       testing::InterpretWasmModuleForTesting(isolate, instance, 0, nullptr);
   if (interpreter_result.failed()) return;
 
+  // TODO(clemensb): Use this function in {WasmExecutionFuzzer::FuzzWasmModule},
+  // which currently duplicates the logic.
+
+  // The WebAssembly spec allows the sign bit of NaN to be non-deterministic.
+  // This sign bit can make the difference between an infinite loop and
+  // terminating code. With possible non-determinism we cannot guarantee that
+  // the generated code will not go into an infinite loop and cause a timeout in
+  // Clusterfuzz. Therefore we do not execute the generated code if the result
+  // may be non-deterministic.
+  if (interpreter_result.possible_nondeterminism()) return;
+
   // Try to instantiate and execute the module_object.
   maybe_instance = isolate->wasm_engine()->SyncInstantiate(
       isolate, &thrower, module_object,