Floating Point regression in NoFib's `imaginary/integrate` benchmark
It appears that recent master commits fail to pass NoFib. Specifically, imaginary/integrate fails with a stdout mismatch in modes norm and slow (but not fast, which was used by CI):
../../runstdtest/runstdtest ./integrate -o1 integrate.stdout -o1 integrate.stdout -ghc-timing +RTS -V0 -RTS 1000000;
0.64user 0.00system 0:00.65elapsed 100%CPU (0avgtext+0avgdata 11252maxresident)k 0inputs+16outputs (0major+1491minor)pagefaults 0swaps
././integrate +RTS -V0 -RTS 1000000 < /dev/null
expected stdout not matched by reality
--- integrate.stdout 2019-11-20 16:38:31.157747042 +0100
+++ /tmp/runtest553570.1 2021-03-20 18:12:57.094954877 +0100
@@ -1 +1 @@
-9.093955583391733e28
+1.9105614312239304e29
make: *** [../../mk/target.mk:101: runtests] Error 1The first commit with which I could reproduce the issue was 4196969c. Its direct parent, f78f001c, doesn't report an output mismatch.
I suspect that the different literal desugaring produces floating point literals that are associated slightly differently.
I think that benchmark may be flawed anyway: I accumulates an ever-growing FP error. While fast still manages to output 0 at the end, the other modes report absurdly high deviations from the expected 0.
We should diagnose if we got something wrong and fix it before we release 9.2.