1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
ppc: 0.969
x86: 0.937
user-level: 0.919
graphic: 0.916
architecture: 0.906
semantic: 0.899
performance: 0.893
debug: 0.839
device: 0.807
mistranslation: 0.801
vnc: 0.760
kernel: 0.733
virtual: 0.721
PID: 0.717
files: 0.714
socket: 0.701
assembly: 0.693
boot: 0.689
KVM: 0.683
network: 0.669
permissions: 0.669
risc-v: 0.668
VMM: 0.661
TCG: 0.649
hypervisor: 0.647
peripherals: 0.640
arm: 0.602
register: 0.601
i386: 0.589
--------------------
ppc: 0.871
performance: 0.053
assembly: 0.045
debug: 0.043
files: 0.028
semantic: 0.020
TCG: 0.020
register: 0.015
virtual: 0.007
user-level: 0.006
PID: 0.006
architecture: 0.005
kernel: 0.004
hypervisor: 0.003
device: 0.003
network: 0.002
boot: 0.002
socket: 0.002
VMM: 0.001
risc-v: 0.001
vnc: 0.001
graphic: 0.001
x86: 0.001
permissions: 0.001
peripherals: 0.001
mistranslation: 0.001
KVM: 0.000
arm: 0.000
i386: 0.000
floating point emulation can fail to set FE_UNDERFLOW
Floating point emulation can fail to set FE_UNDERFLOW in some circumstances. This shows up often in glibc's "math" tests. A similar test is attached.
This is similar to bug #1841442, but not the same problem, and I don't think the fix will be in the same code.
On ppc64le native:
--
$ gcc -c -O2 fma.c
$ gcc -O2 test-fma.c fma.o -lm -o test-fma
$ ./test-fma $(./test-fma)
fma(0x1.ffffffffffffcp-1022, 0x1.0000000000001p-1, 0x0.0000000000001p-1022)
0x0
0xa000000
FE_INEXACT FE_UNDERFLOW
0x1p-1022
--
On qemu-system-ppc64:
--
$ ./test-fma $(./test-fma)
fma(0x1.ffffffffffffcp-1022, 0x1.0000000000001p-1, 0x0.0000000000001p-1022)
0x0
0x2000000
FE_INEXACT
0x1p-1022
--
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/cohuck/tags/s390x-20190822' into staging
- 864ab31 Update version for v4.1.0-rc4 release
There are worse symptoms on qemu-x86_64, but this is apparently not surprising per https://bugs.launchpad.net/qemu/+bug/1841442/comments/6.
Responding to the patch https://lists.nongnu.org/archive/html/qemu-ppc/2019-08/msg00404.html, it seems to work for "double", but not for "float". Test case attached.
The float test failure is part of a larger problem for target/powerpc in which all float routines are implemented incorrectly. They are all implemented as double operations with rounding to float as a second step. Which not only produces incorrect exceptions, as in this case, but incorrect numerical results from the double rounding.
This should probably be split to a separate bug...
A patch for this bug has been merged here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=cbc65a8f22b29680f3
... can we close this ticket now or is there more to do?
Comment #5 suggested splitting the "float" issue to a separate bug, which was done some time ago (bug #1841592).
I think this ticket can be closed.
Ok, thanks for the pointer to the other bug! So I'm closing this one now.
|