blob: abe47d57e577e031d729f234cb65e916cc9f58dd (
plain) (
blame)
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
|
performance: 0.868
architecture: 0.865
device: 0.806
VMM: 0.806
PID: 0.780
graphic: 0.777
user-level: 0.774
network: 0.771
ppc: 0.765
files: 0.756
permissions: 0.736
kernel: 0.714
socket: 0.713
debug: 0.699
semantic: 0.699
vnc: 0.686
virtual: 0.684
arm: 0.682
risc-v: 0.660
peripherals: 0.629
assembly: 0.607
hypervisor: 0.605
register: 0.598
boot: 0.560
mistranslation: 0.520
TCG: 0.502
x86: 0.361
i386: 0.325
KVM: 0.260
Strange floating-point behaviour under Windows with some CPU models
Description of problem:
I'm encountering a very weird bug with some floating-point maths code, but only under very specific configurations. First I thought it was a Clang bug, but then further digging eventually showed it to only occur under Windows VMs with specific QEMU CPU options, I'm not certain whether it is a QEMU/KVM bug or a Windows bug, but thought starting here would be easiest.
When compiled under MSVC Clang with modern CPU instructions disabled (e.g. `-march=pentium3` or `-march=pentium-mmx`), the `floorf()` call in the following program always returns 0.0, while the truncation works correctly:
```
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
float n = atof(argv[1]);
printf("n = %f\n", n);
float f = floorf(n);
printf("f = %f\n", f);
float c = (int)(n);
printf("c = %f\n", c);
return 0;
}
```
Example output on an affected VM:
```
C:\Users\Administrator> floorf-p3.exe 10
n = 10.000000
f = 0.000000
c = 10.000000
C:\Users\Administrator> floorf-p4.exe 10
n = 10.000000
f = 10.000000
c = 10.000000
```
(`floorf-p3.exe` was compiled with `-march=pentium3` and `floorf-p4.exe` with `-march=pentium4` above)
I've tried a few QEMU CPU models on a variety of Intel/AMD VM hosts and two different Windows versions (10 and Server 2022), and observed the following:
* `host-passthrough` - works (on AMD and Intel hosts)
* `qemu64` - broken
* `EPYC-Milan` - works
* `Westmere` - works
* `Penryn` - broken
(I also reported this via the mailing list, but I think it might've swallowed my post)
|