floating point emulation can fail to set FE_INEXACT
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Floating point emulation can fail to set FE_INEXACT in some circumstances. This shows up quite often in glibc's "math" tests. A similar test is attached.
On ppc64le native:
--
$ gcc nextafter.c -o nextafter -lm
$ ./nextafter $(./nextafter)
0x0000000000000001 0.000000
0x0
0xa000000
FE_INEXACT FE_UNDERFLOW
0x0000000000000000 0.000000
--
On x86_64:
--
$ gcc nextafter.c -o nextafter -lm
$ ./nextafter $(./nextafter)
0x0000000000000001 0.000000
0x0
0x30
FE_INEXACT FE_UNDERFLOW
0x0000000000000000 0.000000
--
Using qemu-system-ppc64
--
$ ./nextafter $(./nextafter)
0x0000000000000001 0.000000
0x0
0x8000000
FE_UNDERFLOW
0x0000000000000000 0.000000
--
Using qemu-x86_64:
--
$ ./nextafter $(./nextafter)
0x0000000000000001 0.000000
0x0
0x0
0x0000000000000000 0.000000
--
QEMU versions vary, but not too much, and are pretty close to git HEAD:
- 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/
- 864ab31 Update version for v4.1.0-rc4 release
Since the issue happens nearly identically on different targets, I suspect the issue lies somewhere in fpu/softfloat.c.
Well, maybe yes and maybe no. What you've done is choose two targets
whose floating point emulation have not been well maintained.
If I try this same test on aarch64, it passes:
$ ~/a.out 0x0000000000000001
0x0000000000000001 0.000000
0x0
0x18
FE_INEXACT FE_UNDERFLOW
0x0000000000000000 0.000000
$ ./aarch64- linux-user/ qemu-aarch64 ~/a.out 0x0000000000000001
0x0000000000000001 0.000000
0x0
0x18
FE_INEXACT FE_UNDERFLOW
0x0000000000000000 0.000000