On Tue, 7 Apr 2020 at 10:29, Richard Biener <richard.guent...@gmail.com> wrote: > > On Tue, Apr 7, 2020 at 10:26 AM Jonathan Wakely <jwakely....@gmail.com> wrote: > > > > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell <nat...@acm.org> wrote: > > > > > > On 4/6/20 4:34 AM, Martin Liška wrote: > > > > > > > > > > > May I please ping Jason, Nathan and Jonathan who can help us here? > > > > > > On IRC Martin clarified the question as essentially 'how do you pair up > > > operator new and operator delete calls?' (so you may delete them if the > > > object is not used). > > > > > > I am not sure you're permitted to remove those calls in general. All I > > > can find is [expr.new]/12 > > > 'An implementation is allowed to omit a call to a replaceable global > > > allocation function (17.6.2.1, 17.6.2.2). When it does so, the storage > > > is instead provided by the implementation or provided by extending the > > > allocation of another new-expression.' > > > > At https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295#c6 Richard Smith > > summarised the rules as "new-expressions, like std::allocator, may > > obtain storage by calling 'operator new', but it's unspecified how > > often it's called and with what arguments." > > > > So if our optimisation is removing the calls to base::operator new and > > base::operator delete, but not the B::operator new call, then it seems > > to be working at the wrong level. It should be eliding any calls to > > operator new and operator delete at the point of the new-expression > > and delete-expression, not leaving one call to operator new present > > and then removing another one (which leaves the call "partially > > removed"). > > Well, the question is how to identify "operator new and operator delete at the > point of the new-expression and delete-expression". Currently we're > just matching up "is this a new/delete operator" and the dataflow of the > pointer. In the PR it was suggested the actual called methods should have > the same DECL_CONTEXT. Honza suggested the context should have the > "same" ODR type (or be global). > > You make it sound it's much harder and the parser needs to build the > relation? You also suggest the "validness" is only OK in the context > of std::allocator and based on the unspecifiedness of the number of > allocations from the standard library.
I don't think Richard's summary or my paraphrasing intends to say it only applies to std::allocator.
