https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125652
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
We're lowering nb_iterations_upper_bound via maybe_lower_iteration_bound,
through niter analysis triggered from VRP:
if (!found_exit)
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "Reducing loop iteration estimate by 1; "
"undefined statement must be executed at the last
iteration.\n");
record_niter_bound (loop, widest_int::from
(loop->nb_iterations_upper_bound,
SIGNED) - 1,
false, true);
}
and we find _6 = _4 - _5 which we've figured imposes an iteration bound of one
previously which seems wrong.
SCEV analyzes this to
{-2147483624, +, -9223372036854775808(OVF)}<nw>_1
but the 2nd iteration value should be 9223372032559808557 IIRC. The
<nw> looks bogus to me. ranger computes the range of _6 to
[irange] long int [-4611686020574871528, -4611686020574871528][-2147483624,
-2147483624][4611686016279904280, 4611686016279904280][9223372034707292184,
9223372034707292184] MASK 0xc000000000000000 VALUE 0x3fffffff80000018
SCEV analyzes
h_21 = {1, +, 4611686018427387904}_1
_4 = h_21 + -2147483627 as {-2147483626, +, 4611686018427387904}_1
_5 = ~h_21 as {-2, +, -4611686018427387904}_1
chrec_fold_plus_poly_poly the turns the _4 - _5 step into
-9223372036854775808(OVF).
In r16-2781-gafafae097232e7 I catched some cases for analyzing a SCC itself,
but here it's one of the core workers, where we run into the very same issue.
