[Bug libstdc++/109442] Dead local copy of std::vector not removed from function

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 12 Apr 2023, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
> 
> --- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
> (In reply to Jonathan Wakely from comment #10)
> > I would prefer if we don't deviate, and get Clang to clarify things instead
> > of reinventing something that looks similar but isn't.
> 
> I suppose as long as the common subset of semantics that the library cares
> about works the same way, it's OK.
> 
> It would be bad if the library needs to use extra checks beyond __has_builtin
> to discover which "flavour" of __builtin_operator_new is present.

So if we can get clarification that __builtin_operator_new/delete
allow at least all transforms as if using a new or delete expression
then we can use the same representation as that in the middle-end
for now (just set the CALL_FROM_NEW_OR_DELETE_P flag).

If the builtins provide _additional_ guarantees then we can make use
of those only when we extend things on the middle-end side.

Now we then only need to make the C++ frontend "mangle" the
__builtin_operator_new/delete calls to the "correct" allocation function.
I suppose the goal is to resolve to exactly the same symbols as
when not using the builtins.