https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #16 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 > > Jakub Jelinek <jakub at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |redi at gcc dot gnu.org > > --- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #14) > > If that's valid then all bets for this PR are off since f() then > > _can_ change v.size (). > > Well, in C++ the ctors are typically defined inline, so if we wanted and they > would be inline the FE could do some quick check whether the ctor could leak > the this address or some address derived from it and we could do the > optimization only if we prove that the copy constructor (and default > constructor?) doesn't do this. Yes, with IPA we could also figure out cases where arguments / return by reference could be effectively restrict.
