[Bug tree-optimization/110129] New: Possible wrong-code on -O2 and above (affecting versions from GCC-10.1 onward)

[Bug tree-optimization/110129] New: Possible wrong-code on -O2 and above (affecting versions from GCC-10.1 onward)

[haoxintu at gmail dot com]

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

            Bug ID: 110129
           Summary: Possible wrong-code on -O2 and above (affecting
                    versions from GCC-10.1 onward)
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi,

Please consider the following code, which makes GCC output different results on
-O0/1 and -O2/3/s. Note that all the GCC-10.1 (including) onwards versions
behave the same.

$cat test.c
#include <stdio.h>
int c = 0;
int ids = 0;
struct {
  int a;
} b;
void __attribute__((noinline)) marker_1() {
    printf(" b%db ", 1);
    ids++;
}
int d(int e) {
  b.a = 0;
  for (e = 0; e < 8; e++)
    for (c = 0; c < 9; c++)
      if (c){
        for (; e; )
            ;
      }
  return b.a;
}
int main() {
  int f[1] = {0};
  if (d(c), f)
    marker_1();
  printf("%d\n", ids);
}

$gcc-trunk -w -O1 test.c ;./a.out
(hang)
$gcc-trunk -w -O2 test.c ;./a.out
b1b 1

$gcc-10.1 -w -O1 test.c ;./a.out
(hang)
$gcc-10.1 -w -O2 test.c ;./a.out
b1b 1

$gcc-9.5 -w -O1 test.c ;./a.out
(hang)
$gcc-9.5 -w -O2 test.c ;./a.out
b1b 1


GCC version:
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
COLLECT_LTO_WRAPPER=/opt/compiler-explorer/gcc-trunk-20230605/bin/../libexec/gcc/x86_64-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20230605/configure
--prefix=/opt/compiler-explorer/gcc-build/staging
--enable-libstdcxx-backtrace=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,objc,obj-c++,go,d,rust,m2 --enable-ld=yes
--enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build-gcc-b48890844d94092fdf6e9c941af4a47b9c0ce982-binutils-2.40
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230605 (experimental)
(Compiler-Explorer-Build-gcc-b48890844d94092fdf6e9c941af4a47b9c0ce982-binutils-2.40) 

Example in GodBolt: https://godbolt.org/z/3YhczK7oj


Thanks,
Haoxin

[Bug tree-optimization/110129] Possible wrong-code on -O2 and above (affecting versions from GCC-10.1 onward)

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-06-05

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So in C++, it is required that forward process happens so GCC (due to the
-ffinite-loops option which is only enabled for -O2 and above) will remove
infinite loops for C++.

Now your goldbolt link is using the C++ front-end while your comment says using
C front-end. 

Once I change goldbolt to using C sources, the infinite loop is NOT removed as
expected (as -ffinite-loops is only enabled for C++).

[Bug tree-optimization/110129] Possible wrong-code on -O2 and above (affecting versions from GCC-10.1 onward)

[haoxintu at gmail dot com]

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

--- Comment #2 from Haoxin Tu <haoxintu at gmail dot com> ---
(In reply to Andrew Pinski from comment #1)
Oops, my bad. Thank you for pointing this out. I didn't notice the front-end is
C++ in GodBolt.

I have another similar case, can you take a look, please?

```
#include <stdint.h>
#include <stdio.h>
struct {
  int32_t a;
} b;
int8_t c;
int ids = 0;
void __attribute__((noinline)) marker_1() {
    printf(" b%db ", 1);
    ids++;
}
uint8_t d(int8_t e) {
    b.a = 0;
f:
  for (; e < 8;) {
    for (; e;)
      ;
    goto f;
  }
  return b.a;
}
int main() {
  int32_t g[1] = {0};
  if (d(c), g)
    marker_1();
  printf("%d\n", ids);
}

```


$gcc-trunk -w -O3 s.c ; ./a.out
(hang)
$clang-trunk -w -O3 s.c ; ./a.out
b1b 1

Godbolt link: https://godbolt.org/z/Kn6cv3hjf

GCC hangs on it while Clang can successfully run it. From my understanding, the
goto-statement in function d should not be executed but it seems GCC does. Did
I miss anything here? Thanks!

[Bug tree-optimization/110129] Possible wrong-code on -O2 and above (affecting versions from GCC-10.1 onward)

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=94392
         Resolution|---                         |INVALID

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>Did I miss anything here? Thanks!

Yes clang is incorrect in removing the infinite loop.

See bug 94392 comment #3

[Bug tree-optimization/110129] Possible wrong-code on -O2 and above (affecting versions from GCC-10.1 onward)

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #3)
> >Did I miss anything here? Thanks!
> 
> Yes clang is incorrect in removing the infinite loop.
> 
> See bug 94392 comment #3

The loop around via goto is not removable in C11 based on that comment so I am
not 100% sure if clang is doing the correct thing but GCC is valid doing the
valid thing of not removing it (it is valid to keep the infinite loops in).