Bug 1950764: Work Around Crash on Intel Raptor Lake CPU
21 points by luu 3 days ago | 5 comments

bri3d 3 minutes ago
Linked in the Bugzilla thread is a really nice in depth investigation of the same issue with high register aliases in a similar algorithm (Huffman coding) but in an entirely different product: https://fgiesen.wordpress.com/2025/05/21/oodle-2-9-14-and-in... .

It's concerning that Intel don't seem to have been responsive to anyone with respect to this issue and it doesn't appear to have an official errata yet.

reply
Polizeiposaune 24 minutes ago
Details of the errata from a comment in the diff:

"Write both dist bytes as a single 2-byte store. This avoids the `movb %ch, [mem]` instruction pattern (store from high-byte register alias) that LLVM otherwise emits when dist arrives as a wide register. That pattern triggers the Intel Raptor Lake CPU errata, causing silent 2-byte stores that corrupt the adjacent `len` byte."

reply
dmitrygr 17 minutes ago
modifying source to avoid an assembly isntr isn't a fix... this need a compiler fix most likely, or a microcode fix, if possible.
reply
mike_hock 23 minutes ago
Uh ... working around this in each and every piece of software sounds like a non-starter? Intel should be on the hook to fix this.
reply
Polizeiposaune 18 minutes ago
Use of the "h" register slices (bits 8..15) by compilers is thankfully pretty rare -- otherwise this would have been noticed much sooner!

Agner Fog's optimization guide says "Any use of the high 8-bit registers AH, BH, CH, DH should be avoided because it can cause false dependences and less efficient code."

reply