[Bug tree-optimization/103079] New: wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs)

[Bug tree-optimization/103079] New: wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs)

[zhendong.su at inf dot ethz.ch]

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

            Bug ID: 103079
           Summary: wrong code at -Os and -O2 on x86_64-linux-gnu (the
                    generated code hangs)
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This appears to be a recent regression (from GCC 11.2).

[602] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211104 (experimental) [master r12-4879-g3fd0723f0a3] (GCC) 
[603] % 
[603] % gcctk -O1 small.c; ./a.out
[604] % 
[604] % gcctk -Os small.c
[605] % timeout -s 9 10 ./a.out
Killed
[606] % 
[606] % cat small.c
int a, b = -2;
static int c() {
  if (b)
    return b;
}
int main() {
  int d = 0;
  if (c()) {
    if (!a)
      d = b;
    while (d > -1)
      ;
  }
  return 0;
}

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|wrong code at -Os and -O2   |[12 Regression] wrong code
                   |on x86_64-linux-gnu (the    |at -Os and -O2 on
                   |generated code hangs)       |x86_64-linux-gnu (the
                   |                            |generated code hangs) since
                   |                            |r12-4871-g502ffb1f389011b2
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |amacleod at redhat dot com,
                   |                            |marxin at gcc dot gnu.org
   Last reconfirmed|                            |2021-11-04
           Priority|P3                          |P1
   Target Milestone|---                         |12.0
      Known to work|                            |11.2.0
     Ever confirmed|0                           |1
      Known to fail|                            |12.0
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Confirmed, started with r12-4871-g502ffb1f389011b2.

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=103061

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
It may be the same problem that miscompiles 527.cam4_r benchmark.

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The problem is latent though. The issue is reassociatation introduces an
unconditional use of an uninitilized vairable:
Before
  if (b.1_3 != 0)
    goto <bb 4>; [34.00%]
  else
    goto <bb 3>; [66.00%]

  <bb 3> [local count: 116348739]:
  if (_5(D) != 0)
    goto <bb 4>; [50.00%]
  else
    goto <bb 8>; [50.00%]
After:
  _6 = _5(D) | b.1_3;
  _7 = _6 != 0;
  if (_7 != 0)
    goto <bb 3>; [34.00%]
  else
    goto <bb 7>; [66.00%]

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #3)
> The problem is latent though. The issue is reassociatation introduces an
> unconditional use of an uninitilized vairable:

Whoops that is not the issue here though.

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
> static int c() {
>   if (b)
>     return b;
> }

Yes, one can use the return value as long as the function returns a value.
This means, c() can be used iff b != 0.

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
VRP2:
Predicate evaluates to: DON'T KNOW
Matching expression match.pd:1972, gimple-match.c:819
Matching expression match.pd:1975, gimple-match.c:892
Matching expression match.pd:1982, gimple-match.c:952
Not folded
Folding PHI node: d_5 = PHI <b.0_1(3), 0(4)>
Queued PHI for removal.  Folds to: 0
Folding statement: if (d_5 >= 0)
gimple_simplified to if (1 != 0)
gimple_simplified to if (1 != 0)
Folded into: if (1 != 0)

Is it because of the uninitilized variable causing this to be done this way?

Here is a testcase which does not need an inline function but it shows that
there needs to be an uninitilized variable on a path and all.
int a, b = -2;
int main() {
  int d = 0;
  int t;
  if (b)
    goto t1;
  if (t) {
t1:
    if (!a)
      d = b;
    while (d > -1)
      ;
  }
  return 0;
}

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
=========== BB 2 ============
Imports: b.0_1  t_4(D)
Exports: b.0_1  t_4(D)  _6
         _6 : b.0_1(I)  t_4(D)(I)
t_4(D)  UNDEFINED
    <bb 2> [local count: 176285970]:
    b.0_1 = b;
    _6 = b.0_1 | t_4(D);
    if (_6 != 0)
      goto <bb 3>; [34.00%]
    else
      goto <bb 7>; [66.00%]

2->3  (T) b.0_1 :       UNDEFINED
2->3  (T) t_4(D) :      UNDEFINED
2->3  (T) _6 :  int [-INF, -1][1, +INF]

I think 2->3 (T) b.0_1 : UNDEFINED is wrong.  if b.0_1 is 1 then 1 | UNDEF
is still 1 and there's nothing "undefined" in evaluating if (1 | UNDEF !+ 0).

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, I find the vrp-details dump not really useful with all the ranger
"debug" appearing _after_ the folding of stmts.  Can we instead have
this somehow interleaved?

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

[amacleod at redhat dot com]

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

--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> ---
Created attachment 51735
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51735&action=edit
patch for the undefined bit

(In reply to Richard Biener from comment #7)
> =========== BB 2 ============
> Imports: b.0_1  t_4(D)
> Exports: b.0_1  t_4(D)  _6
>          _6 : b.0_1(I)  t_4(D)(I)
> t_4(D)  UNDEFINED
>     <bb 2> [local count: 176285970]:
>     b.0_1 = b;
>     _6 = b.0_1 | t_4(D);
>     if (_6 != 0)
>       goto <bb 3>; [34.00%]
>     else
>       goto <bb 7>; [66.00%]
> 
> 2->3  (T) b.0_1 :       UNDEFINED
> 2->3  (T) t_4(D) :      UNDEFINED
> 2->3  (T) _6 :  int [-INF, -1][1, +INF]
> 
> I think 2->3 (T) b.0_1 : UNDEFINED is wrong.  if b.0_1 is 1 then 1 | UNDEF
> is still 1 and there's nothing "undefined" in evaluating if (1 | UNDEF !+ 0).

yeah looks like gori calculations just assumes an undefined argument makes
everything undefined..  we should probably just left the op1/op2_range routines
handle it.
We can't actually know b.0_1 if the branch is taken because of the undefined,
so it'll get calculated as varying. With the untested patch, we now get

2->3  (T) t_4(D) :      UNDEFINED
2->3  (T) _6 :  int [-INF, -1][1, +INF]
2->7  (F) b.0_1 :       int [0, 0]
2->7  (F) t_4(D) :      UNDEFINED
2->7  (F) _6 :  int [0, 0] 

we do know that b.0_1 is 0 on the false side...

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

[amacleod at redhat dot com]

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

--- Comment #10 from Andrew Macleod <amacleod at redhat dot com> ---
That patch wont generally work until rangeops op1_range routines are adjusted
to deal with undefined being passed in.. I think it assumes until now that its
been trimmed out.


(In reply to Richard Biener from comment #8)
> Btw, I find the vrp-details dump not really useful with all the ranger
> "debug" appearing _after_ the folding of stmts.  Can we instead have
> this somehow interleaved?

well  the block you quoted is an after-the fact dumping of everything ranger
knows after its been run.   That info is hard to interleave with the folding.  

The traces interleave with the folding messages, but I haven't gotten to the
point where I can interleave the same kind of information.. 

I'll look to improve that once things settle down a bit and see how much of
that I can integrate into the folder routines to dump it as we go.

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Macleod <amacleod@gcc.gnu.org>:

https://gcc.gnu.org/g:004afb984beb6efbe25f44a5857b1c27ebc2ec82

commit r12-4921-g004afb984beb6efbe25f44a5857b1c27ebc2ec82
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Thu Nov 4 11:07:28 2021 -0400

    Treat undefined operands as varying in GORI.

    If the LHS is UNDEFINED simply stop calculating.  Treat op1 and op2
    as VARYING if they are UNDEFINED.

            PR tree-optimization/103079
            gcc/
            * gimple-range-gori.cc (gimple_range_calc_op1): Treat undefined as
            varying.
            (gimple_range_calc_op2): Ditto.

            gcc/testsuite/
            * gcc.dg/pr103079.c: New.

[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

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

--- Comment #12 from Andrew Macleod <amacleod at redhat dot com> ---
fixed