On Thu, Feb 5, 2026 at 4:46 PM Jonathan Wakely <[email protected]> wrote:
> On Thu, 5 Feb 2026 at 15:30, Tomasz Kaminski <[email protected]> wrote: > > > > > > > > On Tue, Aug 26, 2025 at 5:47 PM Jonathan Wakely <[email protected]> > wrote: > >> > >> On Tue, 26 Aug 2025 at 16:29, Tomasz Kamiński <[email protected]> > wrote: > >> > > >> > This patch introduces a new function, _M_fill_append, which is > invoked when > >> > copies of the same value are appended to the end of a vector. Unlike > >> > _M_fill_insert(end(), n, v), _M_fill_append never permute elements in > place, > >> > so it does not require: > >> > * vector element type to be assignable; > >> > * a copy of the inserted value, in the case where it points to an > >> > element of the vector. > >> > > >> > vector::resize(n, v) now uses _M_fill_append, fixing the > non-conformance where > >> > element types were required to be assignable. > >> > > >> > In addition, _M_fill_insert(end(), n, v) now delegates to > _M_fill_append, which > >> > eliminates an unnecessary copy of v when the existing capacity is > used. > >> > > >> > PR libstdc++/90192 > >> > > >> > libstdc++-v3/ChangeLog: > >> > > >> > * include/bits/stl_vector.h (vector<T>::_M_fill_append): > Declare. > >> > (vector<T>::fill): Use _M_fill_append instead of > _M_fill_insert. > >> > * include/bits/vector.tcc (vector<T>::_M_fill_append): Define > >> > (vector<T>::_M_fill_insert): Delegate to _M_fill_append when > >> > elements are appended. > >> > * testsuite/23_containers/vector/modifiers/moveable.cc: > Updated > >> > copycount for inserting at the end (appending). > >> > * testsuite/23_containers/vector/modifiers/resize.cc: New > test. > >> > * testsuite/backward/hash_set/check_construct_destroy.cc: > Updated > >> > copycount, the hash_set constructor uses insert to fill > buckets > >> > with nullptrs. > >> > --- > >> > v2 modifies additional test case, that I must have missed. > >> > hash_set uses insert to append elements, which no longer creates copy. > >> > > >> > OK for trunk? > >> > >> OK > > > > This is now on trunk for 6mo, and no regression was reported, so I think > it is > > time to backport it, as I have fresh builds. Up to GCC 13? > > OK for 15, 14 and 13. > > It's not a regression (checked back to 4.0.4 on Compiler Explorer) but > it is a non-conformance bug with a few duplicate reports, and the fix > isn't complicated. My only concern is causing new false-positive > middle-end warnings about buffer overflows. Please check the test > results carefully, especially on gcc-13 and gcc-14 which didn't have > -fassume-sane-operator-new-delete yet. > Backported to gcc-15, after testing it on cfarm for x86_64-linux and inspecting all emitted warnings.
