[Bug c/110233] New: Wrong code at -Os on x86_64-linux-gnu

[Bug c/110233] New: Wrong code at -Os on x86_64-linux-gnu

[shaohua.li at inf dot ethz.ch]

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

            Bug ID: 110233
           Summary: Wrong code at -Os on x86_64-linux-gnu
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: shaohua.li at inf dot ethz.ch
  Target Milestone: ---

This seems to be a regression since GCC-12.

Compiler explorer: https://godbolt.org/z/8ab6hz9e1

$ cat a.c
int a, b = 1691021644, c = 1790785003;
short d;
short e() {
  for (; c + 18446744073709551608UL + b - 1691021644 + 18446744073709551608UL -
             1790784987 <=
         2;) {
    int *f[2];
    int g = 0;
    for (; b + (b - 1691021644) - 1691021636 + g < 2; g++)
      f[g] = &a;
    int **h = &f[1];
    d = b;
    if (d)
      ;
    else
      **h = 0;
    return b;
  }
  return 1;
}
int main() { e(); }
$
$ gcc-tk -Os a.c && ./a.out
Segmentation fault
$ gcc-tk -O0 a.c && ./a.out
$
$ gcc-tk -O0 -fsanitize=address,undefined a.c && ./a.out
$

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-06-14
            Summary|Wrong code at -Os on        |[12/13/14 Regression] Wrong
                   |x86_64-linux-gnu            |code at -Os on
                   |                            |x86_64-linux-gnu
          Component|c                           |middle-end
             Status|UNCONFIRMED                 |NEW
      Known to work|                            |11.3.0
      Known to fail|                            |12.1.0
   Target Milestone|---                         |12.4
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.
-fno-ivopts fixes the runtime issue ...

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
VRP2/DOM3 produces the wrong folding for some reason:
Folding statement: _27 = b.6_9 * 2;
Queued stmt for removal.  Folds to: 2147483647

I don't uinderstand how it could get that from:
  # RANGE [irange] long unsigned int [0, 2147483647][18446744071562067968,
+INF]
  _8 = (long unsigned intD.10) c.5_7;
  # VUSE <.MEM_18(D)>
  b.6_9 = bD.2751;
  # RANGE [irange] long unsigned int [0, 2147483647][18446744071562067968,
+INF]
  _10 = (long unsigned intD.10) b.6_9;
  # RANGE [irange] long unsigned int [0, 4294967294][18446744069414584320,
+INF]
  _11 = _8 + _10;
  # RANGE [irange] long unsigned int [0, 813160647][18446744065932777673, +INF]
  _12 = _11 + 18446744070227744969;
  if (_12 <= 2)
    goto <bb 3>; [50.00%]
  else
    goto <bb 9>; [50.00%]
;;    succ:       3 [50.0% (guessed)]  count:357878153 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
;;                9 [50.0% (guessed)]  count:357878153 (estimated locally)
(FALSE_VALUE,EXECUTABLE)

;;   basic block 3, loop depth 0, count 357878153 (estimated locally), maybe
hot
;;    prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED)
;;    pred:       2 [50.0% (guessed)]  count:357878153 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
  _28 = b.6_9 * 2;

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> VRP2/DOM3 produces the wrong folding for some reason:
> Folding statement: _27 = b.6_9 * 2;
> Queued stmt for removal.  Folds to: 2147483647
> 
> I don't uinderstand how it could get that from:

Putting a breakpoint in execute_ranger_vrp() for the VRP2 instance, and dumping
what the ranger knows with debug_ranger() we see:

=========== BB 3 ============
b.6_9   [irange] int [1334323000, +INF] NONZERO 0x7fffffff
    <bb 3> [local count: 357878153]:
    _28 = b.6_9 * 2;
    ivtmp.19_27 = 2147483647;
    ivtmp.22_31 = (unsigned long) &f;
    goto <bb 5>; [100.00%]

ivtmp.19_27 : [irange] unsigned int [2147483647, 2147483647] NONZERO 0x7fffffff
_28 : [irange] int [+INF, +INF] NONZERO 0x7ffffffe
ivtmp.22_31 : [irange] unsigned long [1, +INF]

So on entry to BB3, b.6_9 is [1334323000, +INF].  This comes from the 2->3
edge, which is the only incoming edge to BB3.

Isn't multiplying any number in that range an overflow, and thus undefined?

Ranger is coming back with:

_28 : [irange] int [+INF, +INF] NONZERO 0x7ffffffe

which sounds reasonable, and the reason you're seeing 2147483647.

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

[aldyh at gcc dot gnu.org]

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

--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
FWIW, a less intrusive and probably more correct way of seeing what ranger
knows at this point would be to put a breakpoint where you're seeing:

Queued stmt for removal.  Folds to: 2147483647

This is in tree-ssa-propagate.cc.

There you can do:

(gdb) p cfun->x_range_query->dump (stderr)

which will pick up the current ranger and dump what it knows about the IL,
without tickling any new queries:

...
...
=========== BB 3 ============
b.6_9   [irange] int [1334323000, +INF] NONZERO 0x7fffffff
    <bb 3> [local count: 357878153]:
    _28 = b.6_9 * 2;
    ivtmp.19_27 = 2147483647;
    ivtmp.22_31 = (unsigned long) &f;
    goto <bb 5>; [100.00%]

_28 : [irange] int [+INF, +INF] NONZERO 0x7ffffffe

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > VRP2/DOM3 produces the wrong folding for some reason:
> > Folding statement: _27 = b.6_9 * 2;
> > Queued stmt for removal.  Folds to: 2147483647
> > 
> > I don't uinderstand how it could get that from:
> 
> Putting a breakpoint in execute_ranger_vrp() for the VRP2 instance, and
> dumping what the ranger knows with debug_ranger() we see:
> 
> =========== BB 3 ============
> b.6_9	[irange] int [1334323000, +INF] NONZERO 0x7fffffff
>     <bb 3> [local count: 357878153]:
>     _28 = b.6_9 * 2;
>     ivtmp.19_27 = 2147483647;
>     ivtmp.22_31 = (unsigned long) &f;
>     goto <bb 5>; [100.00%]
> 
> ivtmp.19_27 : [irange] unsigned int [2147483647, 2147483647] NONZERO
> 0x7fffffff
> _28 : [irange] int [+INF, +INF] NONZERO 0x7ffffffe
> ivtmp.22_31 : [irange] unsigned long [1, +INF]
> 
> So on entry to BB3, b.6_9 is [1334323000, +INF].  This comes from the 2->3
> edge, which is the only incoming edge to BB3.
> 
> Isn't multiplying any number in that range an overflow, and thus undefined?

ok, that part makes sense but how did that b.6_9 get that range in the first
place? Because it does not even makes sense.

That is these exports:
2->3  (T) c.5_7 :       [irange] int [1334323000, +INF] NONZERO 0x7fffffff
2->3  (T) _8 :  [irange] long unsigned int [1334323000, 2147483647] NONZERO
0x7fffffff
2->3  (T) b.6_9 :       [irange] int [1334323000, +INF] NONZERO 0x7fffffff
2->3  (T) _10 :         [irange] long unsigned int [1334323000, 2147483647]
NONZERO 0x7fffffff
2->3  (T) _11 :         [irange] long unsigned int [3481806647, 3481806649]
NONZERO 0xcf88273f
2->3  (T) _12 :         [irange] long unsigned int [0, 2] NONZERO 0x3

seems wrong.
We originally had (c and d cause a memory read):
    c.5_7 = c;
    _8 = (long unsigned int) c.5_7;
    b.6_9 = b;
    _10 = (long unsigned int) b.6_9;
    _11 = _8 + _10;
    _12 = _11 + 18446744070227744969;
    if (_12 <= 2)

so _11 export seems correct but _8 and _10 added together needs to be make _11.
Since it is unsigned, the whole range for both numbers can make _11's range;
that is we can't say anything about _8 or _10. Even if _11 is signed, I don't
see how _8 and _10 could be described at all ... since _8 could be 0 and _10
could be 3481806647 and the range that is exported for _8 does not even include
0.

Unless I am missing something obvious here.

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |5.3.0, 5.5.0
      Known to fail|                            |5.2.0
           Keywords|needs-bisection             |

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Oh never mind, the problem is IV-OPTS introducing the overflow.
before IVOPTs we have:
  _1 = b.6_9 + -1691021644;
  _2 = _1 + b.6_9;
  _3 = _2 + -1691021636;
  _4 = _3 + g_13;
Which does not have any overflow ...

But afterwards we have one:
  _28 = b.6_9 * 2;
...

that was broken even in GCC 4.7 and most likely earlier.
I had missed that.

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So what I am suspecting is ranger/VRP information was improved which exposed
the latent bug in IVOPTs.

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

[shaohua.li at inf dot ethz.ch]

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

--- Comment #8 from Shaohua Li <shaohua.li at inf dot ethz.ch> ---
I tried to bisect it and I bisected it to r12-4871-g502ffb1f389

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

[sjames at gcc dot gnu.org]

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

--- Comment #9 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to Shaohua Li from comment #8)
> I tried to bisect it and I bisected it to r12-4871-g502ffb1f389

Could you try bisect further back with -param=vrp2-mode=vrp, or does it work
fine with that?

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

[sjames at gcc dot gnu.org]

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

--- Comment #10 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to Sam James from comment #9)
> (In reply to Shaohua Li from comment #8)
> > I tried to bisect it and I bisected it to r12-4871-g502ffb1f389
> 
> Could you try bisect further back with -param=vrp2-mode=vrp, or does it work
> fine with that?

sorry: =ranger

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

[shaohua.li at inf dot ethz.ch]

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

--- Comment #11 from Shaohua Li <shaohua.li at inf dot ethz.ch> ---
(In reply to Sam James from comment #10)
> (In reply to Sam James from comment #9)
> > (In reply to Shaohua Li from comment #8)
> > > I tried to bisect it and I bisected it to r12-4871-g502ffb1f389
> > 
> > Could you try bisect further back with -param=vrp2-mode=vrp, or does it work
> > fine with that?
> 
> sorry: =ranger

Could you make it clear which parameters I should try? Thanks.

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed by r14-4789-g44e7e4498c3cdc.

*** This bug has been marked as a duplicate of bug 110243 ***