Wrong floating-point emulation on AArch64 with FPCR set to zero

Bug #1793119 reported by Koutheir Attouchi on 2018-09-18
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QEMU
Undecided
Unassigned

Bug Description

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

Koutheir Attouchi (koutheir) wrote :
Emilio G. Cota (cota) wrote :

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

Changed in qemu:
status: New → Confirmed
Koutheir Attouchi (koutheir) wrote :

Thanks for the update. Is there a fix/patch for the issue?

Emilio G. Cota (cota) 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 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

Koutheir Attouchi (koutheir) wrote :

Neither will be sufficient in my use case. IEEE-754 conformance is essential. Thank you for the hints.

Emilio G. Cota (cota) on 2018-10-10
Changed in qemu:
status: Confirmed → Fix Committed
Koutheir Attouchi (koutheir) wrote :

Thanks a lot :-)

Thomas Huth (th-huth) wrote :
Changed in qemu:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers