Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Tue, 7 Apr 2020 at 10:29, Richard Biener <richard.guenther@gmail.com> wrote:
>
> On Tue, Apr 7, 2020 at 10:26 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> >
> > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell <nathan@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.