https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116518
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #7)
> I wonder if DSE can use gimple_call_from_new_or_delete even without
> -fassume-sane-operator-new.
>
> In normal use of operator delete we know that the object in question was
> destroyed and thus memory is undefined.
> Now we mark also __builtin_operator_new/delete uses and in this case we know
> delete can not inspect the memory in useful way since it does not know how
> what libstdc++ does with it.
I think so (sure, all of gimple_call_from_new_or_delete and
DECL_IS_OPERATOR_DELETE_P and DECL_IS_OPERATOR_DELETE_P). That license from
https://eel.is/c++draft/expr.new#14
https://eel.is/c++draft/expr.delete#6
says we can choose not to call the operators and do something else instead
(e.g. do a stack allocation instead), so I think valid code can't rely on the
operator observing the values in the memory.
With the https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668986.html
patch we could guard such optimization on flag_assume_sane_operators_new_delete
!= 0 too just to give people a flag to disable such optimizations. Maybe guard
that way other spots that check DECL_IS_REPLACEABLE_OPERATOR as well.
