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.
