<a href="https://lkml.org/lkml/2023/2/22/982" rel="nofollow">https://lkml.org/lkml/2023/2/22/982</a><p>Seems to be a known errata which was fixed by a microcode update
Lovely reminder of the mess x86 is.<p>fp registers shared with mmx, sse registers (xmm), avx registers (ymm), and a truckload of them.<p>Modern implementations have extremely complex frontends, full of elaborate hacks to get performance despite x86.<p>Complexity breeds bugs, such as this one.
Please don't link lkml.org, use lore instead:
<a href="https://lore.kernel.org/lkml/Y%2FW4x7%2FKFqmDmmR7@thinkstation.cmpxchg8b.net/#r" rel="nofollow">https://lore.kernel.org/lkml/Y%2FW4x7%2FKFqmDmmR7@thinkstati...</a>
Unless you absolutely need the newest for some reason, I think buying CPUs which have been out for a year if not more would be the best way of avoiding hardware bugs like this, as it seems like they've also started using users for random spot-testing instead of verifying against a spec. One would hope they have plenty of esoteric and freely available x86/PC software to use for regression testing, like demoscene productions going back to the 80s (a great way to exercise opcode sequences that compilers might rarely or never create, but should still work), but with the recent CPU bugs, it feels more like "Windows/Linux/$common_OS with $common_software seems to work, ship it!"