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?
