https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388
--- Comment #16 from Marc Glisse <glisse at gcc dot gnu.org> --- [expr.new] now provides some flexibility: "A new-expression may obtain storage for the object by calling an allocation function" (not must) "An implementation is allowed to omit a call to a replaceable global allocation function (18.6.2.1, 18.6.2.2). When it does so, the storage is instead provided by the implementation or provided by extending the allocation of another new-expression. The implementation may extend the allocation of a new-expression e1 to provide storage for a new-expression e2" etc The original example is a bit strange, we know the size n in advance, so the optimization that seems most appealing is to allocate directly at least n ints, essentially inserting the call v.reserve(n) that the user missed. (for a small, constant n where we can unroll the whole loop, it may even not be too hard) This was filed as tree-optimization, so I think it meant to optimize a sequence of new/delete where we can see all uses, not replace std::vector with dynarray in the general case. Now it seems pretty hard to find the right circumstances where this optimization is safely possible and to insert the right runtime checks to avoid overflowing the stack, while there are several simple possibilities for the user to improve performance (boost::small_vector if the vector is often very small, or recycle the vector by making it thread_local if there is no reentrance and the program is not going to miss that memory, etc), so this doesn't sound like it is going to happen any time soon.
