Not a compilers guy, so when you say "eliding loops", do you refer to optimizing out loops that the compiler assumes are side-effect free?

Coming from an embedded background, the form "while (true) { // do nothing of interest }" is seen a lot in embedded code. If your code is interrupt driven, or running certain RTOSes, you would usually see this at the end of main(), since everything happens in interrupts. You might also see this in error handlers, and "unimplemented" interrupt handlers during development, as a way to trap the program without halting / resetting the system completely. If this kind of loop was optimized out / you returned-from-main on your embedded system, interesting and unintended things may happen.

While I've never had problems with these particular loops being optimized out (that I can remember!), I do remember having to do other vary silly hacks to try and tell the compiler not to optimize things out, because something is happening in hardware that it wasn't aware of, so I wonder if this is just a practical way of making sure that this kind of code keeps working with newer compilers, even in the face of aggressive optimization.

Yes, the C and C++ standards allow compilers to eliminate loops which have no side effects (It's actually slightly more tricky than this but whatever, check the spec for the exact details). This can be tough in situations like you say, but also in other places: for example, Rust's semantics do not allow you to elide them, but because we use LLVM, we incidentally inherited this behavior: https://github.com/rust-lang/rust/issues/28728

LLVM has since added a new intrinsic: https://reviews.llvm.org/D38336

This will allow us to fix the bug.

Yes, the optimizer is allowed to completely eliminate side-effect free infinite loops.

Example: https://godbolt.org/g/md86qX