https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109703
--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-13 branch has been updated by Jonathan Wakely <r...@gcc.gnu.org>: https://gcc.gnu.org/g:d50f2599d7b23bdba05a9102645d082ed9bcb05f commit r13-7282-gd50f2599d7b23bdba05a9102645d082ed9bcb05f Author: Kefu Chai <kefu.c...@scylladb.com> Date: Mon May 1 21:24:26 2023 +0100 libstdc++: Set _M_string_length before calling _M_dispose() [PR109703] This always sets _M_string_length in the constructor for ranges of input iterators, such as stream iterators. We copy from the source range to the local buffer, and then repeatedly reallocate a larger one if necessary. When disposing the old buffer, _M_is_local() is used to tell if the buffer is the local one or not (and so must be deallocated). In addition to comparing the buffer address with the local buffer, _M_is_local() has an optimization hint so that the compiler knows that for a string using the local buffer, there is an invariant that _M_string_length <= _S_local_capacity (added for PR109299 via r13-6915-gbf78b43873b0b7). But we failed to set _M_string_length in the constructor taking a pair of iterators, so the invariant might not hold, and __builtin_unreachable() is reached. This causes UBsan errors, and potentially misoptimization. To ensure the invariant holds, _M_string_length is initialized to zero before doing anything else, so that _M_is_local() doesn't see an uninitialized value. This issue only surfaces when constructing a string with a range of input iterator, and the uninitialized _M_string_length happens to be greater than _S_local_capacity, i.e., 15 for the std::string specialization. libstdc++-v3/ChangeLog: PR libstdc++/109703 * include/bits/basic_string.h (basic_string(Iter, Iter, Alloc)): Initialize _M_string_length. Signed-off-by: Kefu Chai <kefu.c...@scylladb.com> Co-authored-by: Jonathan Wakely <jwak...@redhat.com> (cherry picked from commit cbf6c7a1d16490a1e63e9a5ce00e9a5c44c4c2f2)
