https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100861
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |easyhack
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=121717
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #1)
> The warning doesn't do anything special with destroying operator delete or
> any other kinds of the operators (other than scalar vs array). It triggers
> for this test case because it sees the result of ::operator new() being
> passed to Widget::operator delete (Widget*). If Widget::operator delete()
> is inlined (e.g., declared with attribute always_inline) the warning goes
> away just as long as the operator doesn't pass the pointer to the wrong
> overload of delete. Alternatively, if Widget defines a non-inline member
> operator new() that also prevents the warning because calls to both
> operators match.
>
> With that, I'm not sure that suppressing the warning for a destroying
> operator delete() would be a good solution. It seems to me that the right
> fix is to solve the broader problem where one of the operators is inlined
> and the other isn't (similar to pr100485, except with the definitions of
> both operators available in the same translation unit).
destroying_delete_t is special though. There is no corresponding operator new.
so warning on destroying_delete_t being called and the operator new is just the
standard one.
So basically for operator delete with destroying_delete_t should never be
warned about directly. A similar change should be made here as PR 121717.
