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.
