[Bug tree-optimization/101750] New: [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523

[Bug tree-optimization/101750] New: [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523

[clyon at gcc dot gnu.org]

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

            Bug ID: 101750
           Summary: [12 regression] g++.dg/vect/pr99149.cc fails on
                    aarch64 since r12-2523
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Since r12-2523, I've noticed these failures on aarch64:

    g++.dg/vect/pr99149.cc  -std=c++14  scan-tree-dump-times slp2
"stmt.*COMPLEX_FMA" 1
    g++.dg/vect/pr99149.cc  -std=c++14  scan-tree-dump-times slp2
"stmt.*COMPLEX_MUL" 1
    g++.dg/vect/pr99149.cc  -std=c++17  scan-tree-dump-times slp2
"stmt.*COMPLEX_FMA" 1
    g++.dg/vect/pr99149.cc  -std=c++17  scan-tree-dump-times slp2
"stmt.*COMPLEX_MUL" 1
    g++.dg/vect/pr99149.cc  -std=c++2a  scan-tree-dump-times slp2
"stmt.*COMPLEX_FMA" 1
    g++.dg/vect/pr99149.cc  -std=c++2a  scan-tree-dump-times slp2
"stmt.*COMPLEX_MUL" 1
    g++.dg/vect/pr99149.cc  -std=c++98  scan-tree-dump-times slp2
"stmt.*COMPLEX_FMA" 1
    g++.dg/vect/pr99149.cc  -std=c++98  scan-tree-dump-times slp2
"stmt.*COMPLEX_MUL" 1

[Bug tree-optimization/101750] [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523

[clyon at gcc dot gnu.org]

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

Christophe Lyon <clyon at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
             Target|                            |aarch64

[Bug tree-optimization/101750] [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> 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 <rguenth at gcc dot gnu.org> ---
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;

  <bb 2> [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

[tnfchris at gcc dot gnu.org]

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

--- Comment #2 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(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

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de <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 <tnfchris at gcc dot gnu.org> ---
> (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

[tnfchris at gcc dot gnu.org]

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

--- Comment #4 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to rguenther@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 <tnfchris at gcc dot gnu.org> ---
> > (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

[tnfchris at gcc dot gnu.org]

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

--- Comment #5 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
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

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de <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 <tnfchris at gcc dot gnu.org> ---
> 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 (&n);
}

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

[tnfchris at gcc dot gnu.org]

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

--- Comment #7 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to rguenther@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 <tnfchris at gcc dot gnu.org> ---
> > 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 (&n);
> }
> 
> 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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tamar Christina <tnfchris@gcc.gnu.org>:

https://gcc.gnu.org/g:9fcb8ec60302f5f110f94a885b618993c28d18d3

commit r12-2734-g9fcb8ec60302f5f110f94a885b618993c28d18d3
Author: Tamar Christina <tamar.christina@arm.com>
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

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

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

--- Comment #9 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Should be fixed now.