[Bug target/114902] [14/15 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
            Summary|wrong code at -O3 with      |[14/15 Regression] wrong
                   |"-fno-tree-vrp              |code at -O3 with
                   |-fno-expensive-optimization |"-fno-tree-vrp
                   |s -fno-tree-dominator-opts" |-fno-expensive-optimization
                   |on x86_64-linux-gnu         |s -fno-tree-dominator-opts"
                   |                            |on x86_64-linux-gnu
          Component|tree-optimization           |target
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-05-01
     Ever confirmed|0                           |1
             Target|                            |x86_64-linux-gnu

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

Here is a testcase which does not depedent on division by zero trapping:
```

volatile int a, c;
unsigned b = 1;
int main() {
  a = 1;
  for (; c < 2; c++) {
    unsigned t = 1 & ~b;
    int e = -t;
    int f = -~(!!(1 % a));
    if (a == 0) __builtin_trap();
    if (e >= -1)
      e = 1;
    a = e;
  }
  return 0;
}
```

The testcase works on aarch64-linux-gnu with no issues.

The difference between GCC 13 and 14 is on the gimple level but the code looks
correct there.

In GCC 13 .optimized has:
```
  b.0_1 = b;
  _2 = b.0_1 & 1;
  _3 = _2 + 4294967295;
  e_16 = (int) _3;
  _13 = e_16 >= -1;
  e_11 = _13 ? 1 : e_16;
```


While in 14  .optimized has:
```
  b.0_1 = b;
  _2 = ~b.0_1;
  t_13 = _2 & 1;
  _3 = -t_13;
  e_14 = (int) _3;
  _10 = e_14 >= -1;
  e_9 = _10 ? 1 : e_14;
```

Both are valid and correct.
But then it goes wrong after that.
I have not looked where though.