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?