https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Richard Biener from comment #9) > 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 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 the standard library could as well use malloc/free? No. std::allocator is required to use operator new and operator delete to obtain memory, but it's unspecified when or how often it calls them. So it's OK to call them once at startup to obtain ALL THE MEMORY that any std::allocator will ever need for the duration of the program, or to merge allocations, or to elide them completely. But it's not OK to use malloc. std::allocator::allocate says: "The storage for the array is obtained by calling ::operator new (17.6.3), but it is unspecified when or how often this function is called."
