https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 13 Apr 2023, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 > > --- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #12) > > Note maybe the restrict qualification isn't the best representation since > > it doesn't capture the value will die upon function return (does it? I > > gues the DTOR if any will run in caller context and thus stores to it > > are not necessarily "dead"). > > Yes, the dtors will be invoked by the caller and those can inspect the values > and do all kinds of things with them. > In fact, the restrict isn't probably right either, the constructor of the > object in the caller could legally save the address of the object somewhere > else (say global pointer, > or inside of the object, or wherever else) and as long as say the destructor > undoes that, it could be valid. > > Something like: > > struct S { > static bool enabled; > static S *p; > S () : s (0) {} > ~S () { if (enabled) p = nullptr; } > S (const S &x) : s (x.s) { if (enabled) p = this; } > int s; > }; > > [[gnu::noipa]] void > bar (S s) > { > s.s++; > S::p->s = 0; > s.s++; > } > > void > foo () > { > S s; > S::enabled = true; > bar (s); > } If that's valid then all bets for this PR are off since f() then _can_ change v.size ().
