* [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
2024-05-18 20:22 [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
@ 2024-05-18 21:40 ` pinskia at gcc dot gnu.org
2024-05-18 21:40 ` pinskia at gcc dot gnu.org
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-05-18 21:40 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [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
2024-05-18 20:22 [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
2024-05-18 21:40 ` [Bug tree-optimization/115152] [13/14/15 Regression] " pinskia at gcc dot gnu.org
@ 2024-05-18 21:40 ` pinskia at gcc dot gnu.org
2024-05-18 21:53 ` pinskia at gcc dot gnu.org
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-05-18 21:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [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
2024-05-18 20:22 [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
2024-05-18 21:40 ` [Bug tree-optimization/115152] [13/14/15 Regression] " pinskia at gcc dot gnu.org
2024-05-18 21:40 ` pinskia at gcc dot gnu.org
@ 2024-05-18 21:53 ` pinskia at gcc dot gnu.org
2024-05-18 21:54 ` pinskia at gcc dot gnu.org
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-05-18 21:53 UTC (permalink / raw)
To: gcc-bugs
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
```
^ permalink raw reply [flat|nested] 14+ messages in thread
* [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
2024-05-18 20:22 [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
` (2 preceding siblings ...)
2024-05-18 21:53 ` pinskia at gcc dot gnu.org
@ 2024-05-18 21:54 ` pinskia at gcc dot gnu.org
2024-05-20 18:27 ` [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
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-05-18 21:54 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [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
2024-05-18 20:22 [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
` (3 preceding siblings ...)
2024-05-18 21:54 ` pinskia at gcc dot gnu.org
@ 2024-05-20 18:27 ` jakub at gcc dot gnu.org
2024-05-20 18:36 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-05-20 18:27 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [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
2024-05-18 20:22 [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
` (4 preceding siblings ...)
2024-05-20 18:27 ` [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
@ 2024-05-20 18:36 ` jakub at gcc dot gnu.org
2024-05-21 6:38 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-05-20 18:36 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* [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
2024-05-18 20:22 [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
` (5 preceding siblings ...)
2024-05-20 18:36 ` jakub at gcc dot gnu.org
@ 2024-05-21 6:38 ` rguenth at gcc dot gnu.org
2024-05-21 9:20 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-05-21 6:38 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [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
2024-05-18 20:22 [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
` (6 preceding siblings ...)
2024-05-21 6:38 ` rguenth at gcc dot gnu.org
@ 2024-05-21 9:20 ` jakub at gcc dot gnu.org
2024-05-21 11:57 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-05-21 9:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [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
2024-05-18 20:22 [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
` (7 preceding siblings ...)
2024-05-21 9:20 ` jakub at gcc dot gnu.org
@ 2024-05-21 11:57 ` jakub at gcc dot gnu.org
2024-05-22 7:14 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-05-21 11:57 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [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
2024-05-18 20:22 [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
` (8 preceding siblings ...)
2024-05-21 11:57 ` jakub at gcc dot gnu.org
@ 2024-05-22 7:14 ` cvs-commit at gcc dot gnu.org
2024-05-22 7:19 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-05-22 7:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [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
2024-05-18 20:22 [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
` (9 preceding siblings ...)
2024-05-22 7:14 ` cvs-commit at gcc dot gnu.org
@ 2024-05-22 7:19 ` cvs-commit at gcc dot gnu.org
2024-05-22 7:35 ` cvs-commit at gcc dot gnu.org
2024-05-22 11:11 ` jakub at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-05-22 7:19 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 14+ messages in thread
* [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
2024-05-18 20:22 [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
` (10 preceding siblings ...)
2024-05-22 7:19 ` cvs-commit at gcc dot gnu.org
@ 2024-05-22 7:35 ` cvs-commit at gcc dot gnu.org
2024-05-22 11:11 ` jakub at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-05-22 7:35 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 14+ messages in thread
* [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
2024-05-18 20:22 [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
` (11 preceding siblings ...)
2024-05-22 7:35 ` cvs-commit at gcc dot gnu.org
@ 2024-05-22 11:11 ` jakub at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-05-22 11:11 UTC (permalink / raw)
To: gcc-bugs
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+.
^ permalink raw reply [flat|nested] 14+ messages in thread