https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116151
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Yep,
/* Don't warn if the loop doesn't have known constant bound. */
if (!loop->nb_iterations
|| TREE_CODE (loop->nb_iterations) != INTEGER_CST
is the first thing, due to EH the number of iterations isn't known.
edge e = single_exit (loop);
if (e == NULL)
return;
and of course we have an alternate exit. That is, the diagnostic is
quite conservative in assuming you'll exit the loop via EH before
invoking UB.
niter analysis doesn't specifically try to diagnose this but does this
only as an afterthought - otherwise we'd ignore EH exits. There's
a likely upper bound of 55 for example.
We could improve do_warn_aggressive_loop_optimizations by looking
at number_of_iterations_exit of a single non-EH/ABNORMAL edge and
diagnose based on the outcome of that instead of relying on the
overall nb_iterations. That of course has the chance of mis-diagnosing,
so we possibly want to alter the message in such a case.
What makes this a regression is that we now optimize this very early
during EVRP and the internal EH is only present because of a clobber
of 'arr':
<bb 3> :
_1 = arr[i_3];
_9 = g (_1);
<bb 4> :
arr[i_3] = _9;
i_11 = i_3 + 1;
...
<bb 7> :
<L3>:
arr ={v} {CLOBBER(eos)};
resx 1
with -fno-tree-vrp we see this removed by ehcleanup1 which is too late
now and while that removes the internal EH and thus the extra loop exit
external EH is still present (also possibly exiting the loop), making
a diagnostic ignoring an explicit EH edge a reasonable thing to do.
It might also argue that we should perform this specific EH cleanup
earlier.
