1 files changed, 92 insertions, 0 deletions
diff --git a/results/classifier/118/none/1793119 b/results/classifier/118/none/1793119
new file mode 100644
index 00000000..02145378
--- /dev/null
+++ b/results/classifier/118/none/1793119
@@ -0,0 +1,92 @@
+permissions: 0.733
+graphic: 0.717
+semantic: 0.670
+performance: 0.668
+files: 0.658
+arm: 0.655
+debug: 0.638
+architecture: 0.637
+socket: 0.636
+device: 0.615
+hypervisor: 0.601
+peripherals: 0.597
+user-level: 0.582
+PID: 0.580
+register: 0.579
+network: 0.573
+risc-v: 0.560
+x86: 0.557
+vnc: 0.544
+ppc: 0.538
+VMM: 0.536
+assembly: 0.536
+i386: 0.529
+mistranslation: 0.529
+TCG: 0.528
+virtual: 0.521
+KVM: 0.506
+boot: 0.494
+kernel: 0.478
+
+Wrong floating-point emulation on AArch64 with FPCR set to zero
+
+On AArch64, with FPCR set to Zero (i.e., FPU set to IEEE-754 compliant mode), floating-point emulation does not produce the same results as real hardware (e.g., Raspberry Pi 3 with AArch64 Linux).
+
+I attached a sample that reproduces the issue. It divides `x` by `y` and puts the result in `r`. The expected result of the operation is `q`.
+
+Output on real hardware:
+=========================================================
+fpcr = 0x07000000.
+x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023.
+fpcr = 0x00000000.
+x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf023. q = 0x43300fde9cbcf023.
+=========================================================
+
+Notice that after setting FPCR to zero, `r` equals `q`.
+
+Output on qemu 3.0.0 (Linux user-mode emulation):
+=========================================================
+fpcr = 0x07000000.
+x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023.
+fpcr = 0x00000000.
+x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf024. q = 0x43300fde9cbcf023.
+=========================================================
+
+Notice that after setting FPCR to zero, `r` is not equal to `q`.
+
+Also notice that, using another proprietary operating system, the same issue arises between a real board and QEMU. This might be an issue in emulation of the AArch64 instruction "fdiv".
+
+Build command line: aarch64-linux-gnu-gcc -static -O0 -o sample1 sample1.c
+
+
+
+Thanks for your report. This is a known regression on our implementation of f64_div, introduced by cf07323d49 ("fpu/softfloat: re-factor div", 2018-02-21).
+
+We are working on improving FP tests to limit regressions, e.g. see this thread, where the bug you report is first mentioned: https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg01703.html
+
+Thanks for the update. Is there a fix/patch for the issue?
+
+Not yet. There should be a fix before 3.1 is released.
+
+Both 2.12 and 3.0 have this bug, so you might want to consider using 2.11 until the bug gets fixed.
+
+On 18 September 2018 at 19:18, Emilio G. Cota
+<email address hidden> wrote:
+> Not yet. There should be a fix before 3.1 is released.
+>
+> Both 2.12 and 3.0 have this bug, so you might want to consider using
+> 2.11 until the bug gets fixed.
+
+On the other hand 2.11 has a different set of slightly-inaccurate-fp-result
+bugs that are fixed in 3.0, so you get to pick your choice of bug there.
+
+thanks
+-- PMM
+
+
+Neither will be sufficient in my use case. IEEE-754 conformance is essential. Thank you for the hints.
+
+Thanks a lot :-)
+
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5dfbc9e4903c0121140f2
+