[Bug tree-optimization/115152] New: wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu

[Bug tree-optimization/115152] New: wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch]

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

            Bug ID: 115152
           Summary: wrong code at -O3 with "-fno-tree-fre
                    -fno-tree-dominator-opts -fno-tree-loop-im" 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: ---

This appears to be a regression from 12.*, and affects 13.* and later. 

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


[598] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.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 --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240516 (experimental) (GCC) 
[599] % 
[599] % gcctk -O3 small.c; ./a.out
[600] % 
[600] % gcctk -O3 -fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im
small.c
[601] % ./a.out
Aborted
[602] % 
[602] % cat small.c
int a, b, c, d;
char e[1] = {1};
int main() {
  for (a = 0; a < 3; a++)
    for (b = 0; b < 2; b++)
      c = e[0] = e[0] ^ d;
  if (!c)
    __builtin_abort();
  return 0;
}

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|wrong code at -O3 with      |[13/14/15 Regression] wrong
                   |"-fno-tree-fre              |code at -O3 with
                   |-fno-tree-dominator-opts    |"-fno-tree-fre
                   |-fno-tree-loop-im" on       |-fno-tree-dominator-opts
                   |x86_64-linux-gnu            |-fno-tree-loop-im" on
                   |                            |x86_64-linux-gnu
   Target Milestone|---                         |13.3

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-05-18
     Ever confirmed|0                           |1

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

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The bug is in strlen1:
```
maybe_invalidate called for MEM[(char *)&e] = vect_pretmp_76.13_77;
maybe_invalidate returns 1
maybe_invalidate called for MEM[(char *)&e] = vect_pretmp_89.18_79;
maybe_invalidate returns 1
Optimizing: pretmp_34 = e[0];
into: pretmp_34 = 0;
maybe_invalidate called for e[0] = pretmp_34;
  statement may clobber object &e 0 bytes in size
maybe_invalidate returns 1
maybe_invalidate called for c = _5;
maybe_invalidate returns 0
maybe_invalidate called for a = _54;
maybe_invalidate returns 0
maybe_invalidate called for b = 2;
maybe_invalidate returns 0
maybe_invalidate called for __builtin_abort ();
maybe_invalidate returns 0
pointer_query counters:
  index cache size:   0
  index entries:      0
  access cache size:  0
  access entries:     0
  hits:               0
  misses:             0
  failures:           0
  max_depth:          0
```

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
That is it looks like a bad interaction between `Vector(1) char` stores and
reads from char. BUT I don't understand how it gets that badly wrong.

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
            Summary|[13/14/15 Regression] wrong |[13/14/15 Regression] wrong
                   |code at -O3 with            |code at -O3 with
                   |"-fno-tree-fre              |"-fno-tree-fre
                   |-fno-tree-dominator-opts    |-fno-tree-dominator-opts
                   |-fno-tree-loop-im" on       |-fno-tree-loop-im" on
                   |x86_64-linux-gnu            |x86_64-linux-gnu since
                   |                            |r13-455
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r13-455-g1fe04c497d5a16baee6af48a0b08ca99b75724e4
Will have a look.

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ugh, slp creates here V1QImode vectors?  Why?  That can't be ever faster than
just scalar QImode, no?

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> Ugh, slp creates here V1QImode vectors?  Why?  That can't be ever faster
> than just scalar QImode, no?

We do not reject single-lane vectors iff the target happily supports them.
It definitely would have avoided some bugs if we did - but it's also good
we fix those.

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.3                        |13.4

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 13.3 is being released, retargeting bugs to GCC 13.4.

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 58262
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58262&action=edit
gcc15-pr115152.patch

Untested fix.

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:dbc9b45a3c2468ad134b3a9bd4961f7ae6bc1e67

commit r15-766-gdbc9b45a3c2468ad134b3a9bd4961f7ae6bc1e67
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed May 22 09:13:50 2024 +0200

    strlen: Fix up !si->full_string_p handling in count_nonzero_bytes_addr
[PR115152]

    The following testcase is miscompiled because
    strlen_pass::count_nonzero_bytes_addr doesn't handle correctly
    the !si->full_string_p case.
    If si->full_string_p, it correctly computes minlen and maxlen as
    minimum and maximum length of the '\0' terminated stgring and
    clears *nulterm (ie. makes sure !full_string_p in the ultimate
    caller) if minlen is equal or larger than nbytes and so
    '\0' isn't guaranteed to be among those bytes.
    But in the !si->full_string_p case, all we know is that there
    are [minlen,maxlen] non-zero bytes followed by unknown bytes,
    so effectively the maxlen is infinite (but caller cares about only
    the first nbytes bytes) and furthermore, we never know if there is
    any '\0' char among those, so *nulterm needs to be always cleared.

    2024-05-22  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/115152
            * tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes_addr): If
            !si->full_string_p, clear *nulterm and set maxlen to nbytes.

            * gcc.dg/pr115152.c: New test.

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:fc9fb69ad624fd4cc89ff31ad0a7b8d88481c1f7

commit r14-10231-gfc9fb69ad624fd4cc89ff31ad0a7b8d88481c1f7
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed May 22 09:13:50 2024 +0200

    strlen: Fix up !si->full_string_p handling in count_nonzero_bytes_addr
[PR115152]

    The following testcase is miscompiled because
    strlen_pass::count_nonzero_bytes_addr doesn't handle correctly
    the !si->full_string_p case.
    If si->full_string_p, it correctly computes minlen and maxlen as
    minimum and maximum length of the '\0' terminated stgring and
    clears *nulterm (ie. makes sure !full_string_p in the ultimate
    caller) if minlen is equal or larger than nbytes and so
    '\0' isn't guaranteed to be among those bytes.
    But in the !si->full_string_p case, all we know is that there
    are [minlen,maxlen] non-zero bytes followed by unknown bytes,
    so effectively the maxlen is infinite (but caller cares about only
    the first nbytes bytes) and furthermore, we never know if there is
    any '\0' char among those, so *nulterm needs to be always cleared.

    2024-05-22  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/115152
            * tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes_addr): If
            !si->full_string_p, clear *nulterm and set maxlen to nbytes.

            * gcc.dg/pr115152.c: New test.

    (cherry picked from commit dbc9b45a3c2468ad134b3a9bd4961f7ae6bc1e67)

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:53bc98f5355ada17d1629a2d0e96aebd397780c6

commit r13-8792-g53bc98f5355ada17d1629a2d0e96aebd397780c6
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed May 22 09:13:50 2024 +0200

    strlen: Fix up !si->full_string_p handling in count_nonzero_bytes_addr
[PR115152]

    The following testcase is miscompiled because
    strlen_pass::count_nonzero_bytes_addr doesn't handle correctly
    the !si->full_string_p case.
    If si->full_string_p, it correctly computes minlen and maxlen as
    minimum and maximum length of the '\0' terminated stgring and
    clears *nulterm (ie. makes sure !full_string_p in the ultimate
    caller) if minlen is equal or larger than nbytes and so
    '\0' isn't guaranteed to be among those bytes.
    But in the !si->full_string_p case, all we know is that there
    are [minlen,maxlen] non-zero bytes followed by unknown bytes,
    so effectively the maxlen is infinite (but caller cares about only
    the first nbytes bytes) and furthermore, we never know if there is
    any '\0' char among those, so *nulterm needs to be always cleared.

    2024-05-22  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/115152
            * tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes_addr): If
            !si->full_string_p, clear *nulterm and set maxlen to nbytes.

            * gcc.dg/pr115152.c: New test.

    (cherry picked from commit dbc9b45a3c2468ad134b3a9bd4961f7ae6bc1e67)

[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 13.4+/14.2+/15.1+.