logoalt Hacker News

IshKebab • yesterday at 9:52 PM • 2 replies • view on HN

I think that's less likely than you'd expect because the memory ordering model used by C++ and others essentially requires you to write code that works even without x86's total storage order. If you don't then you can get bugs even on x86, because the compiler will violate the ordering you thought you had in your program, even if the CPU doesn't.

Also most software runs on ARM now and I don't think that has actually happened in practice.

Replies

rbanffy • yesterday at 10:06 PM

> Also most software runs on ARM now and I don't think that has actually happened in practice.

At least in my house, ARM cores outnumber x86 cores by at least four to one. And I'm not even counting the 32-bit ARM cores in embedded devices.

There is a lot of space for memory ordering bugs to manifest in all those devices.

wat10000 • yesterday at 11:33 PM

It's definitely a real issue in real code, since the CPU isn't bound by things like function boundaries or alias analysis or pointer validity. For example:

  x = *a;
  if (x) y = *b;
The compiler cannot reorder the load of b before the load of a, because it may not be a valid pointer if x is false. But the CPU is free to speculate long ahead, and if the pointer in b isn't valid, that's fine, the CPU can attempt a speculative load and fail.

It's not particularly common and code that has this issue will probably crash only rarely, but it's not too hard to do.