[Bug libstdc++/94295] use __builtin_operator_new and __builtin_operator_delete when available

["richard-gccbugzilla at metafoo dot co.uk" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #2 from Richard Smith <richard-gccbugzilla at metafoo dot co.uk> ---
(In reply to Marc Glisse from comment #1)
> (In reply to Richard Smith from comment #0)
> > The C++ language rules do not permit optimization (eg, deletion) of direct
> > calls to 'operator new' and 'operator delete'.
> 
> I thought that was considered a bug?

No, it's intentional: if the user directly calls '::operator new(42)' and
they've replaced that function, the replacement function is guaranteed to be
called. In this regard, 'operator new' is just a regular function with a funny
name.

To be clear, the implicit call to 'operator new' produced by, say, 'new int'
*is* optimizable, but a direct explicit call to 'operator new(sizeof(int))' is
not.

> Gcc does optimize those, like it does malloc/free...

That sounds like non-conforming behavior.

> > This bug requests that libstdc++ uses these builtins when available.
> 
> So just in std::allocator, or are there other places?

std::allocator's specification has an explicit provision to permit these
optimizations, see [allocator.members]/4:

"The storage for the array is obtained by calling ::operator new (17.6.2), but
it is unspecified when or how often this function is called."

In Clang + libc++ at least, we interpret that as meaning we can call
'::operator new' zero times if we don't need the storage, just like for a
new-expression, and the LWG members I've talked to about this have agreed that
that's in line with the intent.