id = 2817 title = "Strange floating-point behaviour under Windows with some CPU models" state = "opened" created_at = "2025-02-18T12:02:17.591Z" closed_at = "n/a" labels = ["Softfloat", "target: i386"] url = "https://gitlab.com/qemu-project/qemu/-/issues/2817" host-os = "Debian 12" host-arch = "x86_64" qemu-version = "QEMU emulator version 7.2.13 (Debian 1:7.2+dfsg-7+deb12u7)" guest-os = "Windows 10, Windows Server 2022" guest-arch = "x86_64" description = """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 #include #include int main(int argc, char **argv) { \tfloat n = atof(argv[1]); \tprintf("n = %f\\n", n); \t \tfloat f = floorf(n); \tprintf("f = %f\\n", f); \t \tfloat c = (int)(n); \tprintf("c = %f\\n", c); \t \treturn 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)""" reproduce = "n/a" additional = "n/a"