Wrong floating-point emulation on AArch64 with FPCR set to zero
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
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-
Changed in qemu: | |
status: | Confirmed → Fix Committed |
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