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.

Reply via email to