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

[Jason Merrill <jason@redhat.com>]

On Mon, Apr 6, 2020 at 5:27 AM Richard Biener via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> On Sat, Apr 4, 2020 at 1:53 PM Jan Hubicka <hubicka@ucw.cz> wrote:
> >
> > Hi,
> > thinking a bit of the problem, I guess we could match in addition to
> > DECL_CONTEXT the whole inline stack of both statements and see if there
> > are inlined new/delete operators and if so if they are always in
> > matching pairs.
> >
> > The inline stack is available as
> > for (tree block = gimple_block (call); block && TREE_CODE (block) ==
> BLOCK; block = BLOCK_SUPERCONTEXT (block))
> >   {
> >     tree fn = block_ultimate_origin (block);
> >     if (fn != NULL && TREE_CODE (fn) == FUNCTION_DECL)
> >       do the checking htere.
> >   }
> >
> > But I do not understand what C++ promises here and in what conditions
> > the new/delete pair can be removed.
>
> But if the inline stack matches in pairs then the ultimate new/delete
> call should also
> match, no?  When there's a mismatch in inlining we can't DCE since we
> can't remove
> the extra inlined stmts.
>
> Your failing testcase suggests we never can remove new/delete pairs though
> unless the DECL_CONTEXT is 'final'.  Also the user could have chosen to
> "inline" the side-effect of the new operation manually but not the
> delete one, so
>
> operator delete() { count-- }
>
>   ptr = new A;
>   count++;
>   delete ptr;
>
> is it valid to elide the new/delete pair here?
>

The C++ constraints are (deliberately, I think) vague.  As Nathan quotes,
it just says that a call to a replaceable operator new can be omitted, and
that if it is, the matching delete-expression should not call operator
delete.  This example seems to demonstrate that we should also only
consider the replaceable delete operators, not any operator delete.

Jason