diff options
Diffstat (limited to 'results/classifier/zero-shot/108/other/1793119')
| -rw-r--r-- | results/classifier/zero-shot/108/other/1793119 | 77 |
1 files changed, 77 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1793119 b/results/classifier/zero-shot/108/other/1793119 new file mode 100644 index 000000000..dd49587b0 --- /dev/null +++ b/results/classifier/zero-shot/108/other/1793119 @@ -0,0 +1,77 @@ +permissions: 0.733 +graphic: 0.717 +semantic: 0.670 +performance: 0.668 +files: 0.658 +other: 0.645 +debug: 0.638 +socket: 0.636 +device: 0.615 +PID: 0.580 +network: 0.573 +vnc: 0.544 +KVM: 0.506 +boot: 0.494 + +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 + |