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.