* [Bug middle-end/107107] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
2022-09-30 21:34 [Bug middle-end/107107] New: Wrong codegen from TBAA when stores to distinct same-mode types are collapsed? bugdal at aerifal dot cx
@ 2022-10-01 2:25 ` bugdal at aerifal dot cx
2022-10-01 2:59 ` pinskia at gcc dot gnu.org
` (13 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: bugdal at aerifal dot cx @ 2022-10-01 2:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
--- Comment #1 from Rich Felker <bugdal at aerifal dot cx> ---
There's also a potentially related test case at https://godbolt.org/z/jfv1Ge6v4
- I'm not yet clear on whether it's likely to have the same root cause.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug middle-end/107107] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
2022-09-30 21:34 [Bug middle-end/107107] New: Wrong codegen from TBAA when stores to distinct same-mode types are collapsed? bugdal at aerifal dot cx
2022-10-01 2:25 ` [Bug middle-end/107107] " bugdal at aerifal dot cx
@ 2022-10-01 2:59 ` pinskia at gcc dot gnu.org
2022-10-01 3:02 ` pinskia at gcc dot gnu.org
` (12 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-10-01 2:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed. I don't think it is exactly TBAA which is causing the issue but
rather the way PRE does aliasing walks.
Take:
```
static inline void set_longish(int is_long, void *p, long x)
{
if (is_long)
*(long*)p = x;
else
*(long long*)p = x;
}
static long test(long long *p, int index, int mode)
{
*p = 1;
set_longish(mode, p+index, 2);
return *p;
}
long (*volatile vtest)(long long*, int, int) = test;
#include <stdio.h>
int main(void)
{
long long x;
long result = vtest(&x, 0, 0);
printf("%lu/%llu\n", result, x);
}
```
Which is only difference by which order the if statement (and mode which is
swapped). This case works.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug middle-end/107107] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
2022-09-30 21:34 [Bug middle-end/107107] New: Wrong codegen from TBAA when stores to distinct same-mode types are collapsed? bugdal at aerifal dot cx
2022-10-01 2:25 ` [Bug middle-end/107107] " bugdal at aerifal dot cx
2022-10-01 2:59 ` pinskia at gcc dot gnu.org
@ 2022-10-01 3:02 ` pinskia at gcc dot gnu.org
2022-10-01 3:05 ` [Bug tree-optimization/107107] [10/11/12/13 Regression] " pinskia at gcc dot gnu.org
` (11 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-10-01 3:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to fail| |4.1.2, 4.4.7, 4.5.3
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Here is a testcase which has failed since before 4.1.2:
```
static inline void set_longish(int is_long_long, void *p, long x)
{
if (is_long_long)
*(long long*)p = x;
else
*(long*)p = x;
}
static long test(long long *p, int index, int mode)
{
*p = 1;
set_longish(mode, p+index, 2);
return *p;
}
long (*volatile vtest)(long long*, int, int) = test;
#include <stdio.h>
int main(void)
{
long long x;
long result = vtest(&x, 0, 1);
printf("%lu/%llu\n", result, x);
}
```
The only difference from the original testcase is marking set_longish as static
inline. I suspect what changed between 4.7 and 4.8 for the original testcase is
inlining.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
2022-09-30 21:34 [Bug middle-end/107107] New: Wrong codegen from TBAA when stores to distinct same-mode types are collapsed? bugdal at aerifal dot cx
` (2 preceding siblings ...)
2022-10-01 3:02 ` pinskia at gcc dot gnu.org
@ 2022-10-01 3:05 ` pinskia at gcc dot gnu.org
2022-10-01 3:05 ` pinskia at gcc dot gnu.org
` (10 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-10-01 3:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|middle-end |tree-optimization
Summary|Wrong codegen from TBAA |[10/11/12/13 Regression]
|when stores to distinct |Wrong codegen from TBAA
|same-mode types are |when stores to distinct
|collapsed? |same-mode types are
| |collapsed?
Status|UNCONFIRMED |NEW
Target Milestone|--- |10.5
Last reconfirmed| |2022-10-01
Ever confirmed|0 |1
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note this has been to be a regression since tree level PRE is what is causing
the issue and that was added in GCC 4 or 4.1.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
2022-09-30 21:34 [Bug middle-end/107107] New: Wrong codegen from TBAA when stores to distinct same-mode types are collapsed? bugdal at aerifal dot cx
` (3 preceding siblings ...)
2022-10-01 3:05 ` [Bug tree-optimization/107107] [10/11/12/13 Regression] " pinskia at gcc dot gnu.org
@ 2022-10-01 3:05 ` pinskia at gcc dot gnu.org
2022-10-01 17:08 ` amonakov at gcc dot gnu.org
` (9 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-10-01 3:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Rich Felker from comment #1)
> There's also a potentially related test case at
> https://godbolt.org/z/jfv1Ge6v4 - I'm not yet clear on whether it's likely
> to have the same root cause.
This might be a different issue I think.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
2022-09-30 21:34 [Bug middle-end/107107] New: Wrong codegen from TBAA when stores to distinct same-mode types are collapsed? bugdal at aerifal dot cx
` (4 preceding siblings ...)
2022-10-01 3:05 ` pinskia at gcc dot gnu.org
@ 2022-10-01 17:08 ` amonakov at gcc dot gnu.org
2022-10-01 20:01 ` bugdal at aerifal dot cx
` (8 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: amonakov at gcc dot gnu.org @ 2022-10-01 17:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
Alexander Monakov <amonakov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amonakov at gcc dot gnu.org
--- Comment #6 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Rich Felker from comment #1)
> > There's also a potentially related test case at
> > https://godbolt.org/z/jfv1Ge6v4 - I'm not yet clear on whether it's likely
> > to have the same root cause.
>
> This might be a different issue I think.
Yeah, that's sched2 reordering the accesses (probably cselib is confused).
Needs a separate report.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
2022-09-30 21:34 [Bug middle-end/107107] New: Wrong codegen from TBAA when stores to distinct same-mode types are collapsed? bugdal at aerifal dot cx
` (5 preceding siblings ...)
2022-10-01 17:08 ` amonakov at gcc dot gnu.org
@ 2022-10-01 20:01 ` bugdal at aerifal dot cx
2022-10-06 9:02 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: bugdal at aerifal dot cx @ 2022-10-01 20:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
--- Comment #7 from Rich Felker <bugdal at aerifal dot cx> ---
Second one filed as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
2022-09-30 21:34 [Bug middle-end/107107] New: Wrong codegen from TBAA when stores to distinct same-mode types are collapsed? bugdal at aerifal dot cx
` (6 preceding siblings ...)
2022-10-01 20:01 ` bugdal at aerifal dot cx
@ 2022-10-06 9:02 ` rguenth at gcc dot gnu.org
2022-10-06 9:22 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-10-06 9:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
I will have a look.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
2022-09-30 21:34 [Bug middle-end/107107] New: Wrong codegen from TBAA when stores to distinct same-mode types are collapsed? bugdal at aerifal dot cx
` (7 preceding siblings ...)
2022-10-06 9:02 ` rguenth at gcc dot gnu.org
@ 2022-10-06 9:22 ` rguenth at gcc dot gnu.org
2022-10-06 10:07 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-10-06 9:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is how we value-number for tail-merging. We do
Processing block 1: BB4
Value numbering stmt = MEM[(long int *)_3] = 2;
RHS 2 simplified to 2
No store match
Value numbering store MEM[(long int *)_3] to 2
Setting value number of .MEM_12 to .MEM_12 (changed)
marking outgoing edge 4 -> 5 executable
Processing block 2: BB3
Value numbering stmt = *_3 = 2;
RHS 2 simplified to 2
Setting value number of .MEM_11 to .MEM_12 (changed)
marking outgoing edge 3 -> 5 executable
Processing block 3: BB5
Value numbering stmt = .MEM_10 = PHI <.MEM_11(3), .MEM_12(4)>
Setting value number of .MEM_10 to .MEM_12 (changed)
Value numbering stmt = _9 = *p_5(D);
Setting value number of _9 to 1 (changed)
oops. So we figure that the two stores from '2' are "redundant" which causes
us to only consider one (the wrong one) when later looking up *p_5(D).
That's
if (!resultsame)
{
/* Only perform the following when being called from PRE
which embeds tail merging. */
if (default_vn_walk_kind == VN_WALK)
{
assign = build2 (MODIFY_EXPR, TREE_TYPE (lhs), lhs, op);
vn_reference_lookup (assign, vuse, VN_NOWALK, &vnresult, false);
if (vnresult)
{
VN_INFO (vdef)->visited = true;
return set_ssa_val_to (vdef, vnresult->result_vdef);
}
that's a case I never understood fully (and that seems wrong). That
visited flag set is also odd.
I'm testing a patch.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
2022-09-30 21:34 [Bug middle-end/107107] New: Wrong codegen from TBAA when stores to distinct same-mode types are collapsed? bugdal at aerifal dot cx
` (8 preceding siblings ...)
2022-10-06 9:22 ` rguenth at gcc dot gnu.org
@ 2022-10-06 10:07 ` cvs-commit at gcc dot gnu.org
2022-10-06 10:08 ` [Bug tree-optimization/107107] [10/11/12 " rguenth at gcc dot gnu.org
` (4 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-10-06 10:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:
https://gcc.gnu.org/g:85333b9265720fc4e49397301cb16324d2b89aa7
commit r13-3126-g85333b9265720fc4e49397301cb16324d2b89aa7
Author: Richard Biener <rguenther@suse.de>
Date: Thu Oct 6 11:20:16 2022 +0200
tree-optimization/107107 - tail-merging VN wrong-code
The following fixes an unintended(?) side-effect of the special
MODIFY_EXPR expression entries we add for tail-merging during VN.
We shouldn't value-number the virtual operand differently here.
PR tree-optimization/107107
* tree-ssa-sccvn.cc (visit_reference_op_store): Do not
affect value-numbering when doing the tail merging
MODIFY_EXPR lookup.
* gcc.dg/pr107107.c: New testcase.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug tree-optimization/107107] [10/11/12 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
2022-09-30 21:34 [Bug middle-end/107107] New: Wrong codegen from TBAA when stores to distinct same-mode types are collapsed? bugdal at aerifal dot cx
` (9 preceding siblings ...)
2022-10-06 10:07 ` cvs-commit at gcc dot gnu.org
@ 2022-10-06 10:08 ` rguenth at gcc dot gnu.org
2022-10-17 13:10 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-10-06 10:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to work| |13.0
Summary|[10/11/12/13 Regression] |[10/11/12 Regression] Wrong
|Wrong codegen from TBAA |codegen from TBAA when
|when stores to distinct |stores to distinct
|same-mode types are |same-mode types are
|collapsed? |collapsed?
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug tree-optimization/107107] [10/11/12 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
2022-09-30 21:34 [Bug middle-end/107107] New: Wrong codegen from TBAA when stores to distinct same-mode types are collapsed? bugdal at aerifal dot cx
` (10 preceding siblings ...)
2022-10-06 10:08 ` [Bug tree-optimization/107107] [10/11/12 " rguenth at gcc dot gnu.org
@ 2022-10-17 13:10 ` cvs-commit at gcc dot gnu.org
2022-12-12 16:33 ` [Bug tree-optimization/107107] [10/11 " cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-10-17 13:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:
https://gcc.gnu.org/g:ff0a274e5c3026b105c7f51126fa51f8178fa42c
commit r12-8838-gff0a274e5c3026b105c7f51126fa51f8178fa42c
Author: Richard Biener <rguenther@suse.de>
Date: Thu Oct 6 11:20:16 2022 +0200
tree-optimization/107107 - tail-merging VN wrong-code
The following fixes an unintended(?) side-effect of the special
MODIFY_EXPR expression entries we add for tail-merging during VN.
We shouldn't value-number the virtual operand differently here.
PR tree-optimization/107107
* tree-ssa-sccvn.cc (visit_reference_op_store): Do not
affect value-numbering when doing the tail merging
MODIFY_EXPR lookup.
* gcc.dg/pr107107.c: New testcase.
(cherry picked from commit 85333b9265720fc4e49397301cb16324d2b89aa7)
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug tree-optimization/107107] [10/11 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
2022-09-30 21:34 [Bug middle-end/107107] New: Wrong codegen from TBAA when stores to distinct same-mode types are collapsed? bugdal at aerifal dot cx
` (11 preceding siblings ...)
2022-10-17 13:10 ` cvs-commit at gcc dot gnu.org
@ 2022-12-12 16:33 ` cvs-commit at gcc dot gnu.org
2023-01-26 13:05 ` [Bug tree-optimization/107107] [10 " cvs-commit at gcc dot gnu.org
2023-01-26 13:06 ` rguenth at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-12-12 16:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:
https://gcc.gnu.org/g:fa11fc62ddee81a8bc3e69d5e3180695a6dbb666
commit r11-10417-gfa11fc62ddee81a8bc3e69d5e3180695a6dbb666
Author: Richard Biener <rguenther@suse.de>
Date: Thu Oct 6 11:20:16 2022 +0200
tree-optimization/107107 - tail-merging VN wrong-code
The following fixes an unintended(?) side-effect of the special
MODIFY_EXPR expression entries we add for tail-merging during VN.
We shouldn't value-number the virtual operand differently here.
PR tree-optimization/107107
* tree-ssa-sccvn.c (visit_reference_op_store): Do not
affect value-numbering when doing the tail merging
MODIFY_EXPR lookup.
* gcc.dg/pr107107.c: New testcase.
(cherry picked from commit 85333b9265720fc4e49397301cb16324d2b89aa7)
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug tree-optimization/107107] [10 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
2022-09-30 21:34 [Bug middle-end/107107] New: Wrong codegen from TBAA when stores to distinct same-mode types are collapsed? bugdal at aerifal dot cx
` (12 preceding siblings ...)
2022-12-12 16:33 ` [Bug tree-optimization/107107] [10/11 " cvs-commit at gcc dot gnu.org
@ 2023-01-26 13:05 ` cvs-commit at gcc dot gnu.org
2023-01-26 13:06 ` rguenth at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-01-26 13:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:
https://gcc.gnu.org/g:58e39fcaaf298ff54b6f1a45fa9d15390e8113fb
commit r10-11177-g58e39fcaaf298ff54b6f1a45fa9d15390e8113fb
Author: Richard Biener <rguenther@suse.de>
Date: Thu Oct 6 11:20:16 2022 +0200
tree-optimization/107107 - tail-merging VN wrong-code
The following fixes an unintended(?) side-effect of the special
MODIFY_EXPR expression entries we add for tail-merging during VN.
We shouldn't value-number the virtual operand differently here.
PR tree-optimization/107107
* tree-ssa-sccvn.c (visit_reference_op_store): Do not
affect value-numbering when doing the tail merging
MODIFY_EXPR lookup.
* gcc.dg/pr107107.c: New testcase.
(cherry picked from commit 85333b9265720fc4e49397301cb16324d2b89aa7)
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug tree-optimization/107107] [10 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
2022-09-30 21:34 [Bug middle-end/107107] New: Wrong codegen from TBAA when stores to distinct same-mode types are collapsed? bugdal at aerifal dot cx
` (13 preceding siblings ...)
2023-01-26 13:05 ` [Bug tree-optimization/107107] [10 " cvs-commit at gcc dot gnu.org
@ 2023-01-26 13:06 ` rguenth at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-01-26 13:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Known to fail| |10.4.0
Known to work| |10.4.1
Resolution|--- |FIXED
--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 16+ messages in thread