Backported to gcc-13. On Fri, Feb 6, 2026 at 11:02 AM Tomasz Kaminski <[email protected]> wrote:
> > > On Fri, Feb 6, 2026 at 9:47 AM Tomasz Kaminski <[email protected]> > wrote: > >> >> >> 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. >> > Backported to gcc-14. Rebuilding and testing the patch on gcc-13. >
