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

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

[zhendong.su at inf dot ethz.ch]

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

            Bug ID: 112581
           Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
                    (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 should be a very recent regression as it does not seem to reproduce with
the latest build on Compiler Explorer. 


[530] % 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/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231117 (experimental) (GCC) 
[531] % 
[531] % gcctk -Os small.c
[532] % ./a.out
[533] % 
[533] % gcctk -O2 small.c
[534] % timeout -s 9 5 ./a.out
Killed
[535] % 
[535] % cat small.c
int a = -1, b = 2501896061, c, d, e, f = 3, g;
int main() {
  unsigned h;
  int i;
  d = 0;
  for (; d < 1; d++) {
    int j = ~-((6UL ^ a) / b);
    if (b)
    L:
      if (!f)
        continue;
    if (c)
      i = 1;
    if (j) {
      i = 0;
      while (e)
        ;
    }
    g = -1 % b;
    h = ~(b || h);
    f = g || 0;
    a = a || 0;
    if (!a)
      h = 0;
    while (h > 4294967294)
      if (i)
        break;
    if (c)
      goto L;
  }
  return 0;
}

[Bug middle-end/112581] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs)

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
It might be one of the x86 specific target patches ...

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
            Version|unknown                     |14.0
             Status|UNCONFIRMED                 |NEW
            Summary|wrong code at -O2 and -O3   |[14 Regression] wrong code
                   |on x86_64-linux-gnu         |at -O2 and -O3 on
                   |(generated code hangs)      |x86_64-linux-gnu (generated
                   |                            |code hangs)
   Last reconfirmed|                            |2023-11-17
           Keywords|                            |needs-bisection
      Known to work|                            |13.2.1
   Target Milestone|---                         |14.0
           Priority|P3                          |P1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs)

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Andrew Pinski from comment #1)
> It might be one of the x86 specific target patches ...

I don't think so, these patches deal specifically with high registers, and:

$ grep %.h pr112581.s

finds none.

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
            Summary|[14 Regression] wrong code  |[14 Regression] wrong code
                   |at -O2 and -O3 on           |at -O2 and -O3 on
                   |x86_64-linux-gnu (generated |x86_64-linux-gnu (generated
                   |code hangs)                 |code hangs) since r14-4661

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r14-4661-g29a4453c7b8a86d242dab89b9e4d222749fd911e

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Looking into what is going wrong.

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
forwprop3 does:
```
  _12 = ~iftmp.7_30;
  h_40 = (unsigned int) _12;
...
  if (h_40 == 4294967295)
```

into:
```
  _75 = (unsigned int) iftmp.7_30;
  if (iftmp.7_30 == 0)
```

Which as far as I can tell is correct.

And then reassociate2 combines:
```
  <bb 18> [local count: 57431765]:
  if (iftmp.7_30 == 0)
    goto <bb 19>; [97.17%]
  else
    goto <bb 20>; [2.83%]

  <bb 19> [local count: 55807730]:
  if (i_27 != 0)
    goto <bb 20>; [100.00%]
  else
    goto <bb 17>; [0.00%]
```
into:
```
  <bb 18> [local count: 57431765]:
  _75 = iftmp.7_30 | i_27;
  _33 = _75 == 0;
  if (_33 != 0)
    goto <bb 17>; [97.17%]
  else
    goto <bb 19>; [2.83%]
```

or
```
if ((_30 == 0) & (i_27 == 0)) goto <17> else goto <19/20>
```
Which looks correct.
I don't see anything going wrong with the patch itself ...

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Wait a minute, h might be uninitialized.


So the issue is inside reassociate which is must not have recognized that
iftmp.7_30 is defined by a maybe an uninitialized variable ...

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
tree-ssa-reassoc.cc needs to call mark_ssa_maybe_undefs and checks
ssa_name_maybe_undef_p similar to the way tree-ssa-ifcombine.cc does it.

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Adding -fdisable-tree-reassoc2 causes the problem not to happen so yes it is a
bug in reassoc. If I get some time next week I will look into adding the
support.

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661 due to reassoc not handling maybe_undefs

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I have a patch but I don't like it since it requires to touch
gimple-if-to-switch.cc since that uses init_range_entry.  Maybe someone else
can come up with a better patch.

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661 due to reassoc not handling maybe_undefs

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org
   Last reconfirmed|2023-11-17 00:00:00         |2023-12-21
             Status|NEW                         |ASSIGNED

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I will going to take a stab at fixing this.

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661 due to reassoc not handling maybe_undefs

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2023-Decembe
                   |                            |r/641368.html
           Keywords|                            |patch

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641368.html

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661 due to reassoc not handling maybe_undefs

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Andrew Pinski <pinskia@gcc.gnu.org>:

https://gcc.gnu.org/g:113475d03b0ab1ab18a509e8e5844c1a43983b24

commit r14-7114-g113475d03b0ab1ab18a509e8e5844c1a43983b24
Author: Andrew Pinski <quic_apinski@quicinc.com>
Date:   Fri Nov 17 20:06:37 2023 -0800

    reassoc vs uninitialized variable [PR112581]

    Like r14-2293-g11350734240dba and r14-2289-gb083203f053f16,
    reassociation can combine across a few bb and one of the usage
    can be an uninitializated variable and if going from an conditional
    usage to an unconditional usage can cause wrong code.
    This uses maybe_undef_p like other passes where this can happen.

    Note if-to-switch uses the function (init_range_entry) provided
    by ressociation so we need to call mark_ssa_maybe_undefs there;
    otherwise we assume almost all ssa names are uninitialized.

    Bootstrapped and tested on x86_64-linux-gnu.

    gcc/ChangeLog:

            PR tree-optimization/112581
            * gimple-if-to-switch.cc (pass_if_to_switch::execute): Call
            mark_ssa_maybe_undefs.
            * tree-ssa-reassoc.cc (can_reassociate_op_p): Uninitialized
            variables can not be reassociated.
            (init_range_entry): Check for uninitialized variables too.
            (init_reassoc): Call mark_ssa_maybe_undefs.

    gcc/testsuite/ChangeLog:

            PR tree-optimization/112581
            * gcc.c-torture/execute/pr112581-1.c: New test.

    Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661 due to reassoc not handling maybe_undefs

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed.