Public bug reported:
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
** Affects: qemu
Importance: Undecided
Status: New
** Tags: aarch64 arm fpcr ieee-754
** Attachment added: "Sample file to reproduce the issue"
https://bugs.launchpad.net/bugs/1793119/+attachment/5190135/+files/sample1.c
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1793119
Title:
Wrong floating-point emulation on AArch64 with FPCR set to zero
Status in QEMU:
New
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1793119/+subscriptions
