https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #4 from Tamar Christina <tnfchris at gcc dot gnu.org> --- (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 <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.
