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