https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
--- Comment #8 from Marc Glisse <glisse at gcc dot gnu.org> --- At some point, we could also think of taking advantage of what the C++ standard (for instance) says: "[intro.progress] The implementation may assume that any thread will eventually do one of the following: (1.1) — terminate, (1.2) — make a call to a library I/O function, (1.3) — perform an access through a volatile glvalue, or (1.4) — perform a synchronization operation or an atomic operation. [ Note: This is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven. — end note ]" The only potential "progress" in this loop is the call to __builtin_ia32_pmovmskb128, but replacing it with a call to a function with attribute((const)) does not help. And if there is no progress in the loop, the loop must be finite. (we could have some new flag if people insist on for(;;); not being optimized away. I would even use a flag -fno-infinite-loop that says that no loop can be infinite, or -fmain-returns that says that no loop is infinite and the program cannot trap or terminate, etc, but that's getting a bit far from this PR)