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