[Bug c++/101480] [11/12 Regression] Miscompiled code involving operator new

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480

--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 19 Jul 2021, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
> 
> Jonathan Wakely <redi at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            See Also|                            |https://gcc.gnu.org/bugzill
>                    |                            |a/show_bug.cgi?id=59894
> 
> --- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
> I don't think this optimization should be on by default. A switch that says
> "this program does not replace operator new and delete" would make it OK. That
> is the subject of PR 59894.

The odd thing is we do

  /* If the call is to a replaceable operator delete and results
     from a delete expression as opposed to a direct call to
     such operator, then we can treat it as free.  */
  if (fndecl
      && DECL_IS_OPERATOR_DELETE_P (fndecl)
      && DECL_IS_REPLACEABLE_OPERATOR (fndecl)
      && gimple_call_from_new_or_delete (stmt))
    return ".co ";
  /* Similarly operator new can be treated as malloc.  */
  if (fndecl
      && DECL_IS_REPLACEABLE_OPERATOR_NEW_P (fndecl)
      && gimple_call_from_new_or_delete (stmt))
    return "mC";

so explicitely asking for the replaceable variants only (well, not sure
if ones that don't have DECL_IS_REPLACEABLE_OPERATOR set are any
"better" or worse here).  Then we have valid_new_delete_pair_p used by
new/delete pair removal which explicitely checks mangled symbol names.