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

tnfchris at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Wed Aug 4 06:51:53 GMT 2021


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.


More information about the Gcc-bugs mailing list