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)