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