[Bug tree-optimization/101750] [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750 Tamar Christina changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Tamar Christina --- Should be fixed now.
[Bug tree-optimization/101750] [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750 --- Comment #8 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:9fcb8ec60302f5f110f94a885b618993c28d18d3 commit r12-2734-g9fcb8ec60302f5f110f94a885b618993c28d18d3 Author: Tamar Christina Date: Wed Aug 4 14:36:15 2021 +0100 [testsuite] Fix trapping access in test PR101750 I believe PR101750 to be a testism. Fix it by giving the class a name. gcc/testsuite/ChangeLog: PR tree-optimization/101750 * g++.dg/vect/pr99149.cc: Name class.
[Bug tree-optimization/101750] [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #7 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #6)
> On Wed, 4 Aug 2021, tnfchris at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
> >
> > --- Comment #5 from Tamar Christina ---
> > And yes the same semantics apply to 'i', but if I read it right the patch
> > in
> > r12-2523 is tracking variables that are read but never written to. So 'i'
> > escaped the same issue because it's written to somewhere.
>
> I don't think we employ any of those C++ specific analyses, but I also
> didn't try to track down what exactly happens. The following
> doesn't reproduce it:
I think we must be since,
class {
a *h;
a *i;
public:
a* j() {
a k = h[0], l = i[g], m = k * i[f];
i[g] = l + m;
i[f] = m;
h = 0; // assign to h, doesn't matter what.
return i;
}
} n;
also fixes it even without giving the class a name.
>
> int f;
> struct X {
> int *q;
> int *r;
> } n;
> void foo (struct X *p)
> {
> p->r[f] = p->q[0] + p->r[f];
> }
> void bar ()
> {
> foo ();
> }
>
> Maybe 'n' becomes local because its type is local. Indeed, that
> seems to happen. So maybe just give the class a name.
giving it a name works too, so I'll do so then and commit it as a trivial
change.
[Bug tree-optimization/101750] [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #6 from rguenther at suse dot de ---
On Wed, 4 Aug 2021, tnfchris at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
>
> --- Comment #5 from Tamar Christina ---
> And yes the same semantics apply to 'i', but if I read it right the patch in
> r12-2523 is tracking variables that are read but never written to. So 'i'
> escaped the same issue because it's written to somewhere.
I don't think we employ any of those C++ specific analyses, but I also
didn't try to track down what exactly happens. The following
doesn't reproduce it:
int f;
struct X {
int *q;
int *r;
} n;
void foo (struct X *p)
{
p->r[f] = p->q[0] + p->r[f];
}
void bar ()
{
foo ();
}
Maybe 'n' becomes local because its type is local. Indeed, that
seems to happen. So maybe just give the class a name.
[Bug tree-optimization/101750] [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750 --- Comment #5 from Tamar Christina --- And yes the same semantics apply to 'i', but if I read it right the patch in r12-2523 is tracking variables that are read but never written to. So 'i' escaped the same issue because it's written to somewhere.
[Bug tree-optimization/101750] [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750 --- Comment #4 from Tamar Christina --- (In reply to rguent...@suse.de from comment #3) > On Tue, 3 Aug 2021, tnfchris at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750 > > > > --- Comment #2 from Tamar Christina --- > > (In reply to Richard Biener from comment #1) > > > On x86_64 the testcase is optimized to the following now: > > > not sure how we conclude that 'n' is not written to anywhere. The issue > > > persists even when I rename 'main' to 'foo' (when it's 'main' we could > > > indeed > > > conclude so). > > > > I think it's because it's concluding that the access of `h` must trap since > > `h` > > is local and uninitialized. > > Hmm, but 'h' is a member of the class object 'n' which is global. > yes but while 'n' is a global, 'h' inside 'n' is private and has no path to be initialized. It's not initialized by 'j()' nor can you do it from the outside with a reference to 'n'. Since 'h' is private it can only be accessed by method members and none write to it. so no matter which context you call 'j()' from the operation must always fail. That's why renaming `main` to `foo` doesn't matter in this case. > > That also explains the abort. Looks like the reducer needs some slight > > adjustment. if I declare `h` static then it works again.
[Bug tree-optimization/101750] [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750 --- Comment #3 from rguenther at suse dot de --- On Tue, 3 Aug 2021, tnfchris at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750 > > --- Comment #2 from Tamar Christina --- > (In reply to Richard Biener from comment #1) > > On x86_64 the testcase is optimized to the following now: > > not sure how we conclude that 'n' is not written to anywhere. The issue > > persists even when I rename 'main' to 'foo' (when it's 'main' we could > > indeed > > conclude so). > > I think it's because it's concluding that the access of `h` must trap since > `h` > is local and uninitialized. Hmm, but 'h' is a member of the class object 'n' which is global. > That also explains the abort. Looks like the reducer needs some slight > adjustment. if I declare `h` static then it works again.
[Bug tree-optimization/101750] [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750 --- Comment #2 from Tamar Christina --- (In reply to Richard Biener from comment #1) > On x86_64 the testcase is optimized to the following now: > not sure how we conclude that 'n' is not written to anywhere. The issue > persists even when I rename 'main' to 'foo' (when it's 'main' we could indeed > conclude so). I think it's because it's concluding that the access of `h` must trap since `h` is local and uninitialized. That also explains the abort. Looks like the reducer needs some slight adjustment. if I declare `h` static then it works again.
[Bug tree-optimization/101750] [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-08-03
CC||tnfchris at gcc dot gnu.org
Priority|P3 |P1
--- Comment #1 from Richard Biener ---
On x86_64 the testcase is optimized to the following now:
int main ()
{
float d$b;
float l$c;
float l$b;
float k$c;
float k$b;
[local count: 1073741824]:
k$b_4 ={v} MEM[(const struct a &)0B].b;
__builtin_trap ();
}
not sure how we conclude that 'n' is not written to anywhere. The issue
persists even when I rename 'main' to 'foo' (when it's 'main' we could indeed
conclude so).
[Bug tree-optimization/101750] [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750 Christophe Lyon changed: What|Removed |Added Target Milestone|--- |12.0 Target||aarch64
