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

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

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

--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Richard Smith from comment #2)
> (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.

Ah, since you are here, and you appeared as an author of N3664 but not N3537
(precisely when this subtlety happened), could you explain why? It isn't
discussed in the paper, complicates the design, and I cannot think of any use
for this distinction (there are workarounds if people don't want their explicit
call elided).

This of course doesn't at all prevent from adding a __builtin_operator_new
option in std::allocator, it only affects how motivated we should be to fix the
non-conformance.