[Bug tree-optimization/110369] New: wrong code on x86_64-linux-gnu

[Bug tree-optimization/110369] New: wrong code on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch]

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

            Bug ID: 110369
           Summary: wrong code 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 appears to be a recent regression. I'm unsure how interesting the test is as
it uses a few non-default flags, but here it is.

Compiler Explorer: https://godbolt.org/z/rvsrfzb1K

[813] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../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
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230622 (experimental) [master r14-924-gd709841ae0f] (GCC) 
[814] % 
[814] % gcctk -O3 -fno-thread-jumps -fsel-sched-pipelining
-fsel-sched-pipelining-outer-loops -fno-split-loops -fno-tree-loop-ivcanon
-fselective-scheduling2 -w small.c
[815] % timeout -s 9 5 ./a.out
Killed
[816] % 
[816] % gcctk -O3 -w small.c; ./a.out
[817] % 
[817] % cat small.c
int printf(const char *, ...);
int a, b[2] = {0, 0}, c;
void d() {
  int e, f;
  for (f = 0; f < 2; f++)
    if (a) {
      for (e = 0; e < 5; e++) {
        printf("%d", b[e]);
        if (c)
          printf("\n");
      }
    }
}
int main() { d(); }

[Bug tree-optimization/110369] wrong code on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I don't think it's wrong code:

110369.c:8:9: warning: iteration 2 invokes undefined behavior
[-Waggressive-loop-optimizations]
    8 |         printf("%d", b[e]);
      |         ^~~~~~~~~~~~~~~~~~
110369.c:7:21: note: within this loop
    7 |       for (e = 0; e < 5; e++) {
      |                   ~~^~~

The behavior changed in r14-338.

[Bug tree-optimization/110369] wrong code on x86_64-linux-gnu

[amonakov at gcc dot gnu.org]

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

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

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

--- Comment #2 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
The loop over 'e' is never entered, because 'a' is zero.

[Bug tree-optimization/110369] [14 Regression] wrong code on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|wrong code on               |[14 Regression] wrong code
                   |x86_64-linux-gnu            |on x86_64-linux-gnu
   Last reconfirmed|                            |2023-06-22
           Keywords|                            |wrong-code
   Target Milestone|---                         |14.0
     Ever confirmed|0                           |1
                 CC|                            |pinskia at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW

[Bug rtl-optimization/110369] [14 Regression] wrong code on x86_64-linux-gnu with sel-scheduling

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[14 Regression] wrong code  |[14 Regression] wrong code
                   |on x86_64-linux-gnu         |on x86_64-linux-gnu with
                   |                            |sel-scheduling
          Component|tree-optimization           |rtl-optimization

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The first difference (after my patch) is in VRP:
Before:
```
Folding statement: f_14 = f_20 + 1;
   Loops range found for f_20: [irange] int [0, 1] NONZERO 0x1 and calculated
range :[irange] int [0, 1] NONZERO 0x1
Matching expression match.pd:2404, gimple-match.cc:852
Matching expression match.pd:2407, gimple-match.cc:925
Matching expression match.pd:2414, gimple-match.cc:985
Matching expression match.pd:1924, gimple-match.cc:802
Matching expression match.pd:1896, gimple-match.cc:720
Global Exported: f_14 = [irange] int [1, 2] NONZERO 0x3
Folded into: f_14 = _18 ? 1 : 2;
```

After:
```
Folding statement: f_14 = f_20 + 1;
   Loops range found for f_20: [irange] int [0, 1] NONZERO 0x1 and calculated
range :[irange] int [0, 1] NONZERO 0x1
Matching expression match.pd:2404, gimple-match.cc:852
Matching expression match.pd:2407, gimple-match.cc:925
Matching expression match.pd:2414, gimple-match.cc:985
Matching expression match.pd:1924, gimple-match.cc:802
Applying pattern match.pd:4720, gimple-match.cc:11377
Applying pattern match.pd:3998, gimple-match.cc:39957
gimple_simplified to _8 = f_20 + 1;
f_14 = _8;
 Registering value_relation (_8 > f_20) (bb12) at _8 = f_20 + 1;
 Registering value_relation (f_14 == _8) (bb12) at f_14 = _8;
Global Exported: f_14 = [irange] int [1, 2] NONZERO 0x3
Folded into: f_14 = _8;
```

Note _18 is defined as:
_18 = f_20 == 0;

Which is ok and 100% correct.

And then another difference:
Before:
```
Folding statement: if (f_14 != 2)

Visiting conditional with predicate: if (f_14 != 2)

With known ranges
        f_14: [irange] int [1, 2] NONZERO 0x3

Predicate evaluates to: DON'T KNOW
Matching expression match.pd:2404, gimple-match.cc:852
Matching expression match.pd:2407, gimple-match.cc:925
Matching expression match.pd:2414, gimple-match.cc:985
Applying pattern match.pd:5945, gimple-match.cc:24663
Matching expression match.pd:1924, gimple-match.cc:802
Applying pattern match.pd:4600, gimple-match.cc:176366
Applying pattern match.pd:3998, gimple-match.cc:39802
gimple_simplified to if (_18 != 0)
Folded into: if (_18 != 0)
```
After:
```
Folding statement: if (f_14 != 2)

Visiting conditional with predicate: if (f_14 != 2)

With known ranges
        f_14: [irange] int [1, 2] NONZERO 0x3

Predicate evaluates to: DON'T KNOW
Matching expression match.pd:2404, gimple-match.cc:852
Matching expression match.pd:2407, gimple-match.cc:925
Matching expression match.pd:2414, gimple-match.cc:985
Not folded
```

I don't get why VRP folded it differently.


Anyways we just have a missed optimization inside VRP after my commit, not
wrong code.

The wrong code is due to sel scheduling.


The code at .optimized:
Before:
```
  if (f_20 == 0)
```
After:
```
  # RANGE [irange] int [-INF, +INF] NONZERO 0x3
  _8 = f_20 + 1;
  if (_8 != 2)
```
(which is basically f_21 != 1 or rather f_21 == 0 here)

[Bug rtl-optimization/110369] [14 Regression] wrong code on x86_64-linux-gnu with sel-scheduling

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Here is another testcase which shows the same behavior but turning off VRP and
a few others:
```
//-fselective-scheduling2  -O3 -fno-thread-jumps -fno-split-loops
-fno-tree-loop-ivcanon  -fsel-sched-pipelining
-fsel-sched-pipelining-outer-loops  -fno-tree-vrp -fno-tree-forwprop

int printf(const char *, ...);
int a, b[2] = {0, 0}, c;
void d() {
  int e, f = 0, f1 = 0;
  for (;;)
  {
    if (a) {
      for (e = 0; e < 5; e++) {
        printf("%d", b[e]);
        if (c)
          printf("\n");
      }
    }
    f = f+1;
    if (f!=2)
      f = 1;
    else
      return;
  }
}
int main() { d(); }
```

The behavior I think changes with the above testcase with r14-162 (but still
just a latent bug)

[Bug rtl-optimization/110369] [14 Regression] wrong code on x86_64-linux-gnu with sel-scheduling

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu.org
           Priority|P3                          |P4

[Bug rtl-optimization/110369] [14/15 Regression] wrong code on x86_64-linux-gnu with sel-scheduling

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|14.0                        |14.2

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 14.1 is being released, retargeting bugs to GCC 14.2.