[PATCH] Check DECL_CONTEXT of new/delete operators.

[Richard Biener]

On Tue, Apr 7, 2020 at 1:46 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Tue, 7 Apr 2020 at 12:40, Richard Biener <richard.guenther@gmail.com> wrote:
> >
> > On Tue, Apr 7, 2020 at 1:30 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> > >
> > > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
> > > > The both operator new and operator delete are looked up in the same
> > > > manner.  The std does not require a 'matching pair' be found.  but it is
> > > > extremely poor form for a class to declare exactly one of operator
> > > > {new,delete}.
> > >
> > > There are unfortunately several such example in the standard!
> > >
> > > I wonder how much benefit we will really get from trying to make this
> > > optimisation too general.
> > >
> > > Just eliding (or coalescing) implicit calls to ::operator new(size_t)
> > > and ::operator delete(void*, size_t) (and the [] and align_val_t forms
> > > of those) probably covers 99% of real cases.
> >
> > IIRC the only reason to have the optimization was to fully elide
> > STL containers when possible.  That brings in allocators and
> > thus non ::new/::delete allocations.
>
> But the vast majority of containers are used with std::allocator, and
> we control that.
>
> Wouldn't it be simpler to add __builtin_operator_new and
> __builtin_operator_delete like clang has, then make std::allocator use
> those, and limit the optimizations to uses of those built-ins?

Sure, that's a viable implementation strathegy.  Another might be

void delete (void *) __attribute__((matching_new(somewhere::new)));

and thus allow the user to relate a new/delete pair (here the FE would
do lookup for 'new' and record for example the mangled assembler name).

That is, we usually try to design a mechanism that's more broadly usable.
But yes, we match malloc/free so matching ::new/::delete by aliasing them
to __builtin_operator_new and __builtin_operator_delete is fair enough.

Not easily usable by other languages with custom allocation though
(fortran allocate/deallocate anyone? that's currently inlined to expose
underlying malloc/free calls for similar reasons)

Richard.