[Bug target/114386] New: [10/11/12 Regression] Miscompile at -O1

[Bug target/114386] New: [10/11/12 Regression] Miscompile at -O1

[patrick at rivosinc dot com]

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

            Bug ID: 114386
           Summary: [10/11/12 Regression] Miscompile at -O1
           Product: gcc
           Version: 12.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
int printf(const char *, ...);
_Bool a, c = 1;
int b, d;
int main() {
  _Bool g = c;
  d = !a ? ({ c > a ? c : a; }) : 0;
  printf("%x\n", d);
}

Commands:
> gcc -O0 red.c -o red.o
> ./red.o
0

> gcc -O1 red.c -o red.o
> ./red.o
1

> gcc -O2 red.c -o red.o
> ./red.o
0

> gcc -O3 red.c -o red.o
> ./red.o
1

Tested/discovered on x86 - gcc v11.4.0.
Issue is not present when targeting risc-v.

Godbolt shows it's a regression starting at 10.1 (with -O1) and resolved as of
13.1.

Godbolt: https://godbolt.org/z/q4P9xs5dx

[Bug tree-optimization/114386] [11/12 Regression] Miscompile at -O1

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
   Target Milestone|---                         |11.5
          Component|target                      |tree-optimization
      Known to fail|                            |13.1.0
            Summary|[10/11/12 Regression]       |[11/12 Regression]
                   |Miscompile at -O1           |Miscompile at -O1

[Bug tree-optimization/114386] [11/12/13 Regression] Miscompile at -O1

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12 Regression]          |[11/12/13 Regression]
                   |Miscompile at -O1           |Miscompile at -O1
   Last reconfirmed|                            |2024-03-18
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Actually this still fails in GCC 13 with a slightly different testcase:
```
_Bool a, c = 1;
int b, d;
int main() {
  _Bool g = c;
  d = !a ? ({ c > a ? c : a; }) : 0;
  __builtin_printf("%x, %x\n", d, (int)g);
}
```

[Bug tree-optimization/114386] [11/12/13 Regression] Miscompile at -O1

[pinskia at gcc dot gnu.org]

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

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
      Known to work|                            |14.0
             Status|NEW                         |ASSIGNED

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
PHIOPT goes from:
```
  if (a.1_1 != 0)
    goto <bb 4>; [INV]
  else
    goto <bb 3>; [INV]

  <bb 3> :
  _5 = MAX_EXPR <a.1_1, g_10>;
  iftmp.0_12 = (int) _5;

  <bb 4> :
  # iftmp.0_8 = PHI <iftmp.0_12(3), 0(2)>
```

to:
```
  _5 = MAX_EXPR <a.1_1, g_10>;
  iftmp.0_8 = 0;
```

Due to:
```
PHI iftmp.0_8 changed to factor conversion out from COND_EXPR.
```

Which seems not to be done on the trunk ...

Mine due it being phiopt.

[Bug tree-optimization/114386] [11/12/13 Regression] Miscompile at -O1

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note the reason why it might work on the trunk is due to replacement of
`MAX_EXPR <c.0_1, a.2_2>` with `c.0_1 | a.2_2` so it might be a latent bug
still on the trunk ...

[Bug tree-optimization/114386] [11/12/13 Regression] Miscompile at -O1

[patrick at rivosinc dot com]

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

--- Comment #4 from Patrick O'Neill <patrick at rivosinc dot com> ---
(In reply to Patrick O'Neill from comment #0)
> ...
> Issue is not present when targeting risc-v.

This was in reference to tip-of-tree gcc - forgot to update this when I
determined the upper bound of the regression. RISC-V is also likely affected in
version 10/latent. Also forgot to mention - found via fuzzer.

Thanks for the quick triage as always Andrew.

[Bug tree-optimization/114386] [11/12/13 Regression] Miscompile at -O1

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Yes this turns out to be a dup of bug 111331 which is already fixed on the GCC
13 branch .

Tested the GCC 13 branch with revision right before
r13-7928-gcda1992a56779e5c60a70f251542a6f662fdfa60 and it and it was broken
before but it is working afterwards.

This is a latent bug for a few years now even.

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

[Bug tree-optimization/114386] [11/12/13 Regression] Miscompile at -O1

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note after my r13-7928-gcda1992a56779e5c60a70f251542a6f662fdfa60 patch we get
from phiopt:
```
  if (a.1_1 != 0)
    goto <bb 4>; [50.00%]
  else
    goto <bb 3>; [50.00%]

  <bb 3> [local count: 536870913]:
  _3 = MAX_EXPR <a.1_1, g_7>;

  <bb 4> [local count: 1073741824]:
  # _2 = PHI <_3(3), 0(2)>

```

Which is correct.

And then later on we get:
```
  if (a.1_1 != 0)
    goto <bb 3>; [50.00%]
  else
    goto <bb 4>; [50.00%]

  <bb 3> [local count: 536870912]:

  <bb 4> [local count: 1073741824]:
  # _2 = PHI <g_7(2), 0(3)>

````

Note the trunk we get finally:
```
  _10 = ~a.1_1;
  _11 = g_6 & _10;
```
Which is the best (well really `a < g` but that is a different known issue).