https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118493
Bug ID: 118493 Summary: std::vector::insert regression in C++03: execution reaches an unreachable program point Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: arseny.kapoulkine at gmail dot com Target Milestone: --- Created attachment 60163 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60163&action=edit reproducer The following patch https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=955202eb2cdbe2bc74c626bce90ee1eac410ad4f adds this line: + 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. To reproduce, compile and run the attached file as follows: g++ test.cpp -std=c++03 -fsanitize=undefined && ./a.out