public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/107114] New: [13 Regression] Failure to discover range results in bogus warning
@ 2022-10-01 17:59 jeffreyalaw at gmail dot com
  2022-10-01 18:01 ` [Bug tree-optimization/107114] " law at gcc dot gnu.org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: jeffreyalaw at gmail dot com @ 2022-10-01 17:59 UTC (permalink / raw)
  To: gcc-bugs

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?

^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2023-02-21 13:51 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-01 17:59 [Bug tree-optimization/107114] New: [13 Regression] Failure to discover range results in bogus warning jeffreyalaw at gmail dot com
2022-10-01 18:01 ` [Bug tree-optimization/107114] " law at gcc dot gnu.org
2022-10-03 15:46 ` amacleod at redhat dot com
2022-10-03 17:37 ` law at gcc dot gnu.org
2022-10-03 18:18 ` amacleod at redhat dot com
2022-10-03 18:21 ` law at gcc dot gnu.org
2022-10-06  9:27 ` rguenth at gcc dot gnu.org
2022-12-22 14:32 ` rguenth at gcc dot gnu.org
2023-02-21 13:51 ` rguenth at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).