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

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Jonathan Wakely from comment #7)
> > I think it's valid in theory. I don't know if it's possible for GCC to do it
> > in practice. There doesn't seem to be anything the library can do to help,
> > so WONTFIX.
> 
> I think it's valid in theory because the implementation of std::vector is
> opaque. It's not required to actually call operator new and operator delete
> to obtain its storage, and so if the library and compiler collaborate to
> provide storage some other way (e.g. using a stack buffer) then that's
> allowed.
> 
> But in practice it's hard to do that.
> 
> Maybe it could be done with a new __builtin_elidable_operator_new and
> __builtin_elidable_operator_delete pair that the library could use, or
> attributes like you suggested in comment 4. That would allow the library to
> say "I'm calling operator new and operator delete because I need to obtain
> memory, but **these particular invocations** are not required to be visible
> to the user, and therefore can be elided in the same way as new expressions
> and delete expressions".
> 
> In fact Clang's __builtin_operator_new already has exactly those semantics:
> 
> https://clang.llvm.org/docs/LanguageExtensions.html#builtin-operator-new-and-
> builtin-operator-delete
> 
> And we already use those builtins if available, see PR 94295.
> 
> So maybe what we need is to implement those.

Yep, looking at that link this is exactly what would be needed.  Note
that in the middle-end we already see the calls to
DECL_IS_REPLACEABLE_OPERATOR_NEW_P and replaceable operator delete.  We
just restrict all optimizations to calls emitted from new/delete expressions.
I'm not sure the clang builtin is exactly providing the new/delete
expression semantics resolving to replaceable operator new/delete or if
there's other details.  That is, I'm curious whether __builtin_operator_new
provides more guarantees than a new/delete expression - the builtin semantics
isn't very well defined unfortunately.  It might be safer to go our own
way here.

I suppose the standard library could as well use malloc/free?  Or is the
standard library required to perform allocation with "replaceable operator
new/delete"?  (I suppose it helps not open-coding the exceptional cases)