ac187c0323
Apparently it happens quite easily that different NaNs are produced in the interpreter than in the execution of the compiled code. This non-determinism caused problems for the fuzzer which compares the equality of the results of the interpreter and the compiled code. I decided therefore to refactor the detection of non-determinism in the interpreter. Instead of tracking whether potentially non-deterministic NaNs were produced, I track now whether potentially non-deterministic NaNs could have been observed. The only way the NaN non-determinism can be observed is by observing the non-deterministic bit pattern of the NaN. AFAICT the only way to observe the bit pattern is with a I(32|64)_REINTERPRET_F(32|64) instruction or with a F(32|64)_STORE followed by a load. Therefore I flag an execution as potentially non-deterministic when either a NaN is reinterpreted to an int, or when a NaN is stored to memory. R=titzer@chromium.org, eholk@chromium.org BUG=682180 Review-Url: https://codereview.chromium.org/2671803002 Cr-Commit-Position: refs/heads/master@{#42917} |
||
---|---|---|
.. | ||
OWNERS | ||
test-managed.cc | ||
test-run-wasm-64.cc | ||
test-run-wasm-asmjs.cc | ||
test-run-wasm-interpreter.cc | ||
test-run-wasm-js.cc | ||
test-run-wasm-module.cc | ||
test-run-wasm-relocation.cc | ||
test-run-wasm-simd-lowering.cc | ||
test-run-wasm-simd.cc | ||
test-run-wasm.cc | ||
test-wasm-breakpoints.cc | ||
test-wasm-stack.cc | ||
test-wasm-trap-position.cc | ||
wasm-run-utils.h |