[Bug c/109967] New: Wrong code at -O2 on x86_64-linux-gnu

[Bug c/109967] New: Wrong code at -O2 on x86_64-linux-gnu

[shaohua.li at inf dot ethz.ch]

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

            Bug ID: 109967
           Summary: Wrong code at -O2 on x86_64-linux-gnu
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: shaohua.li at inf dot ethz.ch
  Target Milestone: ---

For the following code, gcc trunk at -O2 emits the wrong code. This seems to be
a long latent bug since GCC-7 (I tried gcc-7.4 on compiler explorer, which
still emits the wrong result.)

Compiler explorer: https://godbolt.org/z/YGeWedWq7

$ cat a.c
int printf(const char *, ...);
int a, c;
int main() {
  long f[2];
  int e = 0;
  for (; e < 2; e++) {
    {
      char g[20];
      char *b = g;
      int d = 48, e = 0;
      while (d && e < 5)
        b[e++] = d /= 10;
      c = e;
    }
    f[c - 2 + e] = 1;
  }
  a = f[0];
  printf("%d\n", a);
}
$
$ gcc-tk -O0 a.c && ./a.out
1
$ gcc-tk -O2 a.c && ./a.out
4
$
$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-8d5f050dabbf6dd3b992c3b46661848dbcf30d9e/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-8d5f050dabbf6dd3b992c3b46661848dbcf30d9e
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230523 (experimental) (GCC) 
$

[Bug middle-end/109967] Wrong code at -O2 on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-linux-gnu

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So if I initialize f the code works.

Note the gimple level code looks the same.

[Bug middle-end/109967] [10/11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Wrong code at -O2 on        |[10/11/12/13/14 Regression]
                   |x86_64-linux-gnu            |Wrong code at -O2 on
                   |                            |x86_64-linux-gnu
   Target Milestone|---                         |10.5
      Known to work|                            |6.1.0
      Known to fail|                            |7.1.0

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The problem is the Partition code in expand.

Without the ={0,0}, we get:
Partition 1: size 20 align 16
        g       f

With we get:
Partition 1: size 20 align 16
        g
Partition 0: size 16 align 16
        f

[Bug middle-end/109967] [10/11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
   Last reconfirmed|                            |2023-05-26
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

[Bug middle-end/109967] [10/11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu

[davmac at davmac dot org]

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

Davin McCall <davmac at davmac dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davmac at davmac dot org

--- Comment #3 from Davin McCall <davmac at davmac dot org> ---
-fdisable-tree-cunroll avoids it.

This is the take of someone who is new to poking GCC internals, so take this
with a grain of salt, but:

It looks like cunroll duplicates (partially unrolls, I suppose) the inner loop,
meaning that `g' is live in two disjoint ranges, with a CLOBBER between them.

Then later passes (fre5, but disabling it doesn't seem to help) recognise that
&g and &g are the same in both ranges and so use a single temporary for both.
This confuses cfgexpand (as Andrew Pinski notes) because the memory dereference
of the temporary isn't seen as an access of g (in
add_scope_conflicts()/add_scope_conflicts_1()/visit_conflict()). 

I don't understand the IR semantics well enough to know the right fix - perhaps
cunroll should be removing the clobber (does a clobber affect storage lifetime
or only value?), or perhaps cfgexpand should be more conservative when it sees
a memory access.

[Bug middle-end/109967] [10/11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu

[amonakov at gcc dot gnu.org]

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

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

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

--- Comment #4 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
See PR 90348 for the discussion of problematic lifetime semantics.

[Bug middle-end/109967] [11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.

[Bug middle-end/109967] [11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu

[shaohua.li at inf dot ethz.ch]

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

--- Comment #6 from Shaohua Li <shaohua.li at inf dot ethz.ch> ---
Bisected to r9-2635-g78ea9abc201

[Bug middle-end/109967] [11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu

[shaohua.li at inf dot ethz.ch]

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

--- Comment #7 from Shaohua Li <shaohua.li at inf dot ethz.ch> ---
This test case does not reproduce anymore on the current trunk. Maybe one of
the recent fixes fixed the underlying issue as well.

[Bug middle-end/109967] [11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

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

--- Comment #8 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Shaohua Li from comment #7)
> This test case does not reproduce anymore on the current trunk. Maybe one of
> the recent fixes fixed the underlying issue as well.

But we still need to ensure the fix backported into 11/12/13.  And there is
still a chance that the issue might be covered up by an unrelated change.

[Bug middle-end/109967] [11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=111294
                 CC|                            |rguenther at suse dot de

--- Comment #9 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Bisect shows r14-4089 (the fix for PR111294) either fixes or "covers up" the
issue.

[Bug middle-end/109967] [11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Plus we have the r14-7274 workaround on the trunk now, wouldn't that make the
problem go away too?