[Bug tree-optimization/82776] Unable to optimize the loop when iteration count is unavailable.

[glisse at gcc dot gnu.org]

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)