summary refs log tree commit diff stats
path: root/results/classifier/108/other/1841491
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/108/other/1841491')
-rw-r--r--results/classifier/108/other/184149173
1 files changed, 73 insertions, 0 deletions
diff --git a/results/classifier/108/other/1841491 b/results/classifier/108/other/1841491
new file mode 100644
index 000000000..b8c5ad6df
--- /dev/null
+++ b/results/classifier/108/other/1841491
@@ -0,0 +1,73 @@
+other: 0.969
+graphic: 0.916
+semantic: 0.899
+performance: 0.893
+debug: 0.839
+device: 0.807
+vnc: 0.760
+PID: 0.717
+files: 0.714
+socket: 0.701
+boot: 0.689
+KVM: 0.683
+network: 0.669
+permissions: 0.669
+
+floating point emulation can fail to set FE_UNDERFLOW
+
+Floating point emulation can fail to set FE_UNDERFLOW in some circumstances. This shows up often in glibc's "math" tests. A similar test is attached.
+
+This is similar to bug #1841442, but not the same problem, and I don't think the fix will be in the same code.
+
+On ppc64le native:
+--
+$ gcc -c -O2 fma.c
+$ gcc -O2 test-fma.c fma.o -lm -o test-fma
+$ ./test-fma $(./test-fma)
+fma(0x1.ffffffffffffcp-1022, 0x1.0000000000001p-1, 0x0.0000000000001p-1022)
+0x0
+
+0xa000000
+FE_INEXACT FE_UNDERFLOW 
+0x1p-1022
+--
+
+On qemu-system-ppc64:
+--
+$ ./test-fma $(./test-fma)
+fma(0x1.ffffffffffffcp-1022, 0x1.0000000000001p-1, 0x0.0000000000001p-1022)
+0x0
+
+0x2000000
+FE_INEXACT 
+0x1p-1022
+--
+
+QEMU versions vary, but not too much, and are pretty close to git HEAD:
+- 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging
+- 864ab31 Update version for v4.1.0-rc4 release
+
+There are worse symptoms on qemu-x86_64, but this is apparently not surprising per https://bugs.launchpad.net/qemu/+bug/1841442/comments/6.
+
+
+
+
+
+Responding to the patch https://lists.nongnu.org/archive/html/qemu-ppc/2019-08/msg00404.html, it seems to work for "double", but not for "float". Test case attached.
+
+
+
+The float test failure is part of a larger problem for target/powerpc in which all float routines are implemented incorrectly.  They are all implemented as double operations with rounding to float as a second step.  Which not only produces incorrect exceptions, as in this case, but incorrect numerical results from the double rounding.
+
+This should probably be split to a separate bug...
+
+A patch for this bug has been merged here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=cbc65a8f22b29680f3
+... can we close this ticket now or is there more to do?
+
+Comment #5 suggested splitting the "float" issue to a separate bug, which was done some time ago (bug #1841592).
+
+I think this ticket can be closed.
+
+Ok, thanks for the pointer to the other bug! So I'm closing this one now.
+