https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 29 May 2020, ed at catmur dot uk wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349 > > --- Comment #12 from Ed Catmur <ed at catmur dot uk> --- > (In reply to Richard Biener from comment #11) > > Note that for C++ types you can apply memcpy to the placement new is not > > needed since object re-use terminates lifetime of the previous object and > > starts lifetime of a new one. > > Under P0593R6 it has the effect of implicitly creating objects on demand. > Effectively it is supposed to "curse" the double and "bless" the subsequent > uint64_t. Invoking P0593 may be jumping the gun since it's still in LWG, but > Richard (Smith) wants it retroactively applied to C++20 IS as a DR, and that > could still happen. I believe such "curse"/"bless" operation cannot be implemented without overhead(*) and thus I would not recommend to make it apply to all placement new operations. > > Note that while your example performs memcpy dances you are probably > > after a solution that elides all generated code? > > Sure, I assume that memcpy of anything smaller than a page will be elided :) (*) then no longer. > > Note that I do not belive making your examples work as you intend is > > possible in an actual implementation without sacrifying all > > type-based alias analysis. > > Ouch. You might be asked to if and when P0593 goes in (again, assuming I've > understood it correctly). Would it be appropriate to find out what Ville > thinks? Definitely.
