[Bug tree-optimization/101223] New: wrong code at -Os and above on x86_64-linux-gnu

[Bug tree-optimization/101223] New: wrong code at -Os and above on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch]

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

            Bug ID: 101223
           Summary: wrong code at -Os and above on x86_64-linux-gnu
           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: ---

It also affects GCC 11.*, but not GCC 10.*. 

[516] % 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 20210626 (experimental) [master revision
2168bfb8144:f9d3bc42803:5b1ce655b25040048861af6c0264cb667b66fcd7] (GCC) 
[517] % 
[517] % gcctk -O1 small.c; ./a.out
[518] % 
[518] % gcctk -Os small.c
[519] % ./a.out
Aborted
[520] % 
[520] % cat small.c
struct {
  int a : 1;
} b;
int c = 1, d;
int main() {
  for (; d < 2; d++) {
    int e = ~c, f = 0, g;
    if (e) {
      f = c;
      g = b.a;
      b.a = f;
      if (b.a >= g)
        __builtin_abort();
    }
    c = f;
    b.a = g;
  }
  return 0;
}

[Bug tree-optimization/101223] [11/12 Regression] wrong code at -Os and above on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|wrong code at -Os and above |[11/12 Regression] wrong
                   |on x86_64-linux-gnu         |code at -Os and above on
                   |                            |x86_64-linux-gnu
   Target Milestone|---                         |11.2
           Keywords|                            |wrong-code
             Target|                            |x86_64-linux-gnu
            Version|unknown                     |11.0

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |amacleod at redhat dot com
   Last reconfirmed|                            |2021-06-28
     Ever confirmed|0                           |1
            Summary|[11/12 Regression] wrong    |[11/12 Regression] evrp
                   |code at -O2 and above on    |produces wrong code
                   |x86_64-linux-gnu            |

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The problem is in evrp.
Without evrp:
  # f_10 = PHI <0(3), c.0_1(4)>
  # g_11 = PHI <g_12(3), g_21(4)>
  c = f_10;
.....

With VRP:
  <bb 6> :
  # g_11 = PHI <g_12(3), g_21(4)>
  c = 0;

That is wrong.


c.0_1: int VARYING
_2: <unnamed-signed:1> VARYING
_3: <unnamed-signed:1> VARYING
_5: int [-1, 0]
_6: <unnamed-signed:1> VARYING
_8: int [-2147483647, 2]
d.2_9: int VARYING
g_11: int VARYING
g_12: int VARYING
g_15(D): UNDEFINED
e_18: int VARYING
g_21: int [-1, 0]


Huh:
Visiting PHI node: f_10 = PHI <0(3), c.0_1(4)>
    Argument #0 (3 -> 6 executable)
        0: int [0, 0]
    Argument #1 (4 -> 6 executable)
        c.0_1: int [c.0_1, c.0_1]
Meeting
  int [0, 0]
and
  int [c.0_1, c.0_1]
to
  int VARYING
Intersecting
  int VARYING
and
  int VARYING
to
  int VARYING

Visiting PHI node: g_11 = PHI <g_12(3), g_21(4)>
    Argument #0 (3 -> 6 executable)
        g_12: int [g_12, g_12]
    Argument #1 (4 -> 6 executable)
        g_21: int [-1, 0]
Meeting
  int [g_12, g_12]
and
  int [-1, 0]
to
  int VARYING
Intersecting
  int VARYING
and
  int VARYING
to
  int VARYING
Folding PHI node: f_10 = PHI <0(3), c.0_1(4)>
EVRP:hybrid: RVRP found singleton 0
Queued PHI for removal.  Folds to: 0
Folding PHI node: g_11 = PHI <g_12(3), g_21(4)>
recomputation attempt on edge 4->6 for g_21 : Calculated :int VARYING
No folding possible
evrp visiting stmt c = f_10;
Folding statement: c = f_10;
EVRP:hybrid: RVRP found singleton 0
Folded into: c = 0;

We got int VARYING but still folded it to 0.

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Right before we have:
popping range for c.0_1, restoring int VARYING

But still don't see how we could get [0, 0] for the range there.

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12 Regression] evrp     |[11/12 Regression] evrp
                   |produces wrong code         |produces wrong code since
                   |                            |r11-3685-gfcae5121154d1c33
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r11-3685-gfcae5121154d1c33.

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

[aldyh at gcc dot gnu.org]

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

--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
d is used before being defined.  Isn't this entire test bogus?

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
d is not an automatic variable, so is zero initialized.

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

[aldyh at gcc dot gnu.org]

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

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> d is not an automatic variable, so is zero initialized.

Whoops.  Sorry for the noise.

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

[amacleod at redhat dot com]

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

--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> ---
I think this is our old friend 1-bit signed overflow.

for 1 signed bit values, varying is [-1, 0]  

range-op::build_lt checks to see if UB - 1 overflows, and if it does, then the
result is undefined.

wi::sub  sets the overflow flag for 0 - 1 with 1 bit signed...   so the
comparison ends up being undefined, and we then make incorrect choices because
we think we can.

I think we need to, yet again, special case 1-bit signed values here, and
probably in build_gt as well.

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

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

--- Comment #8 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #7)
> wi::sub  sets the overflow flag for 0 - 1 with 1 bit signed...   so the
> comparison ends up being undefined, and we then make incorrect choices
> because we think we can.
Isn't that a bug in wi::sub though?  I think we should fix it rather
than work around it in callers.

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to rsandifo@gcc.gnu.org from comment #8)
> (In reply to Andrew Macleod from comment #7)
> > wi::sub  sets the overflow flag for 0 - 1 with 1 bit signed...   so the
> > comparison ends up being undefined, and we then make incorrect choices
> > because we think we can.
> Isn't that a bug in wi::sub though?  I think we should fix it rather
> than work around it in callers.

How can one write 0 - 1 in 1-bit signed though?  1 isn't in the range...
One can only do 0 + -1 which doesn't overflow, or 0 - -1 which does.

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

[rsandifo at gcc dot gnu.org]

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

--- Comment #10 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
> How can one write 0 - 1 in 1-bit signed though?  1 isn't in the range...
> One can only do 0 + -1 which doesn't overflow, or 0 - -1 which does.
Ah, yeah, of course.  So the issue that 1 doesn't even exist as
a representation for 1-bit signed.  Sorry for the noise…

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

[cvs-commit at gcc dot gnu.org]

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

--- 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:84f7bab89279ca1234fef88929c74caeda8cb55e

commit r12-1986-g84f7bab89279ca1234fef88929c74caeda8cb55e
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Wed Jun 30 14:15:53 2021 -0400

    Fix build_gt and build_lt for signed 1 bit values.

    Signed 1 bit values have a range of [-1, 0] but neither (0 - 1) nor (-1 +
1)
    can be represented.  For signed values, add or subtract -1 as appropriate.

            PR tree-optimization/101223
            gcc/
            * range-op.cc (build_lt): Add -1 for signed values.
            (built_gt): Subtract -1 for signed values.

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

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

[amacleod at redhat dot com]

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

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.

[Bug tree-optimization/101223] [11 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |---
             Status|RESOLVED                    |REOPENED
            Summary|[11/12 Regression] evrp     |[11 Regression] evrp
                   |produces wrong code since   |produces wrong code since
                   |r11-3685-gfcae5121154d1c33  |r11-3685-gfcae5121154d1c33

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Reopening since it was only fixed on the trunk and it was a regression in GCC
11.

[Bug tree-optimization/101223] [11 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:b977e6b29c67be81df882d1f5cc7eb6a5d8c98a0

commit r11-8751-gb977e6b29c67be81df882d1f5cc7eb6a5d8c98a0
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Wed Jun 30 14:15:53 2021 -0400

    Fix build_gt and build_lt for signed 1 bit values.

    Signed 1 bit values have a range of [-1, 0] but neither (0 - 1) nor (-1 +
1)
    can be represented.  For signed values, add or subtract -1 as appropriate.

            PR tree-optimization/101223
            gcc/
            * range-op.cc (build_lt): Add -1 for signed values.
            (built_gt): Subtract -1 for signed values.

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

    (cherry picked from commit 84f7bab89279ca1234fef88929c74caeda8cb55e)

[Bug tree-optimization/101223] [11 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

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

--- Comment #15 from Andrew Macleod <amacleod at redhat dot com> ---
checked into gcc11