https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #32 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #31) > 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). See PR101480 for a reason why to not do this.
