summaryrefslogtreecommitdiffstats
path: root/results/classifier/105/instruction/2817
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-06-03 12:04:13 +0000
committerChristian Krinitsin <mail@krinitsin.com>2025-06-03 12:04:13 +0000
commit256709d2eb3fd80d768a99964be5caa61effa2a0 (patch)
tree05b2352fba70923126836a64b6a0de43902e976a /results/classifier/105/instruction/2817
parent2ab14fa96a6c5484b5e4ba8337551bb8dcc79cc5 (diff)
downloademulator-bug-study-256709d2eb3fd80d768a99964be5caa61effa2a0.tar.gz
emulator-bug-study-256709d2eb3fd80d768a99964be5caa61effa2a0.zip
add new classifier result
Diffstat (limited to 'results/classifier/105/instruction/2817')
-rw-r--r--results/classifier/105/instruction/281764
1 files changed, 64 insertions, 0 deletions
diff --git a/results/classifier/105/instruction/2817 b/results/classifier/105/instruction/2817
new file mode 100644
index 00000000..55f396c9
--- /dev/null
+++ b/results/classifier/105/instruction/2817
@@ -0,0 +1,64 @@
+instruction: 0.930
+device: 0.806
+graphic: 0.777
+network: 0.771
+socket: 0.713
+semantic: 0.699
+vnc: 0.686
+assembly: 0.607
+other: 0.579
+boot: 0.560
+mistranslation: 0.520
+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)