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

["jeffreyalaw at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 107114
           Summary: [13 Regression] Failure to discover range results in
                    bogus warning
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jeffreyalaw at gmail dot com
                CC: aldyh at redhat dot com, amacleod at redhat dot com
  Target Milestone: ---
            Target: arc-elf

After this change (from me):

aa360fbf68b11e54017e8fa5b1bdb87ce7c19188

I'm seeing a case on arc-elf where VRP/Ranger is no longer identifying the
range of one object as not including zero.  As a result a test later in the CFG
isn't simplified and we get a bogus warning.

What's really interesting here is my change simplifies the CFG by eliminating a
handful of blocks in the affected loop (including a sub-loop).

Here's the testcase:
/* { dg-do compile } */

short a;
long b;
void fn1()
{
  int c = a = 1;
  for (; a; a++)
    {
      for (; 9 <= 8;)
        for (;;) {
            a = 20;
            for (; a <= 35; a++)
              ;
line:;
        }
      if ((c += 264487869) == 9)
        {
          unsigned *d = 0;
          for (; b;)
            d = (unsigned *)&c;
          if (d)
            for (;;)
              ;
        }
    }
  goto line;
}



Compiled on arc-elf with -Os -Wall:
[jlaw@X10DRH-iT gcc]$ ./cc1 -Os -Wall k.c -quiet
k.c: In function ‘fn1’:
k.c:17:14: warning: iteration 8 invokes undefined behavior
[-Waggressive-loop-optimizations]
   17 |       if ((c += 264487869) == 9)
      |              ^~
k.c:8:10: note: within this loop
    8 |   for (; a; a++)
      |          ^

If we look at the .vrp2 dump before my change we have this:

Global Exported: a_lsm.14_26 = [irange] short int [1, 9] NONZERO 0xf

This is key because we have this in the CFG:

;;   basic block 7, loop depth 1, count 21262216 (estimated locally), maybe hot
;;    prev block 6, next block 1, flags: (NEW, REACHABLE, VISITED)
;;    pred:       2 [always]  count:1346238 (estimated locally)
(FALLTHRU,EXECUTABLE) k.c:8:3
;;                6 [always]  count:20092794 (estimated locally)
(FALLTHRU,DFS_BACK,EXECUTABLE)
  # a_lsm.14_26 = PHI <1(2), _11(6)>
  # a_lsm_flag.15_28 = PHI <0(2), 1(6)>
  # c_lsm.16_29 = PHI <1(2), _6(6)>
  if (a_lsm.14_26 != 0) 
    goto <bb 6>; [94.50%]
  else 
    goto <bb 3>; [5.50%]


We really want to simplify that condition to a compile-time constant.  That
avoids the incorrect warning.

After my change we do not discover the range for a_lsm.14_26 in vfp2 and
naturally conditional above isn't simplified and the warning gets triggered.



Maybe I'm missing something subtle, but it looks like the simplifications done
in dom3 are resulting in vrp2 missing discovery of the key range.  It's not
clear to me why that's that's happening though.

Thoughts?