https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126194
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #10)
> (In reply to Richard Biener from comment #7)
> > r11-3612-g4f4ced28826ece replaced the former use of
> > DECL_IS_REPLACEABLE_OPERATOR_DELETE_P with DECL_IS_OPERATOR_DELETE_P
> > (throughout the code base). Jason, what's this about?
>
> That change was primarily to clarify that CALL_FROM_NEW_OR_DELETE_P is about
> whether the call results from a syntactic new or delete expression, not
> about what function gets called.
>
> And also, the rule (https://eel.is/c++draft/expr.delete#6) about omitting a
> call to op delete does not depend on whether the operator is replaceable,
> like the corresponding rule for new does
> (https://eel.is/c++draft/expr.new#14). The rule for delete depends only on
> whether the corresponding new was omitted.
>
> But perhaps that's not the rule that the find_func_aliases_for_call is
> about, so changing it in that commit was wrong. Perhaps this spot is meant
> to parallel the handling in gimple_call_fnspec, so it should use the same
> condition (including checking flag_assume_sane...)?
The condition find_func_aliases_for_call want's to check is whether the
delete expression is plain delete, no overload whatsoever, so no side-effects
besides deallocation. That might not even need CALL_FROM_NEW_OR_DELETE_P
if it's still the standard library provided delete.
The proposed patch passed testing, I'll cook up a testcase for the testsuite
and will post it.
