https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I believe to match clang++ behavior the needed change would be:
--- gcc/gimple.cc.jj 2024-11-14 18:26:16.877459015 +0100
+++ gcc/gimple.cc 2024-11-15 13:40:43.484711373 +0100
@@ -1605,7 +1605,7 @@ gimple_call_fnspec (const gcall *stmt)
if (fndecl
&& DECL_IS_REPLACEABLE_OPERATOR_NEW_P (fndecl)
&& gimple_call_from_new_or_delete (stmt))
- return "m ";
+ return "mP";
return "";
}
Clearly ::operator delete, even when called from delete expression, isn't
assumed not to change global state nor read it by clang++.
Or of course if we want to go even further than that, we could return "mC" and
let it behave like __builtin_malloc.
Though, while perhaps one can somehow derive from the fact that the call can be
omitted the undesirability to visibly change global state (because the compiler
could decide not to call it and thus the global state change wouldn't occur), I
don't see what rationale we'd use for not reading global state, other than that
when using malloc under the hood the operator doesn't do that (visibly).
