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 <hubi...@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
