https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #39 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 15 Jan 2025, arseny.kapoulkine at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 > > Arseny Kapoulkine <arseny.kapoulkine at gmail dot com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |arseny.kapoulkine at gmail > dot com > > --- Comment #38 from Arseny Kapoulkine <arseny.kapoulkine at gmail dot com> > --- > The change that attempts to silence the warning breaks std::vector insert > behavior in certain (most?) cases. > > Specifically, the patch checks: > > + if (__len < (__n + (__old_start - __old_finish))) > > ... which is incorrect, as "start - finish" subtraction order is wrong - it > should be "finish - start". > > The consequences are that insert will trap in some cases depending on how many > elements the vector already has and how many elements are being inserted. For > example, if the vector size and capacity is 768 elements, and 384 elements > (__n) are being inserted, __len computed via _M_check_len(__n) produces 1536 > (doubling the currently allocated capacity). Since __n is 384, __n + (-768) > underflows and produces a very large value that is definitely greater then > __len. Depending on the codegen the trap may or may not happen; it does happen > when building with -fsanitize=undefined without optimizations at least. > > This is part of gcc 14 release; I can only imagine this doesn't break the > world > because the world generally isn't compiling for C++ versions earlier than 2011 > these days. > > Let me know if this should be filed as a separate bug report, or if this > comment suffices. yes, please raise a separate bugreport so we can appropriately prioritize that as important.
