[Bug tree-optimization/107114] [13 Regression] Failure to discover range results in bogus warning

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107114

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-12-22

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed for the diagnostics.  But note the loop in question is basically

 for (a = 1; a != 0; a++)

so it iterates until we wrap to zero (a is 'short', the increment is in
'int' due to promotion so short wrap doesn't invoke undefined overflow).

That means the loop iterates >65000 times which means the repeated add
of 264487869 overflows.

At the point we emit this diagnostic this will always happen so the
diagnostic is correct?

We do fail to optimize if ((c += 264487869) == 9) though, but likely
because VRP no longer iterates.  c starts from 1 and we only add positive
numbers the range for it should be [1, +INF].  The entry to the line:
tail loop has this optimized and the add removed as dead code.  That's
what possibly happened before - we optimized this branch and thus DCEd
the add?

Anyhow, on x86_64 we mangle the whole thing a bit more than on arc-elf.

Huh, it looks like arc-elf disables GIMPLE loop optimizers.  I can reproduce
the diagnostic on x86_64 with -fno-tree-loop-optimize.
gcc/common/config/arc/arc-common.cc has

    { OPT_LEVELS_SIZE, OPT_ftree_loop_optimize, NULL, 0},

for whatever reason.  -ftree-loop-optimize "fixes" the diagnostic.

But as said, I think the diagnostic is correct.