https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #14 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #11)
> Why does it think we're calling it with max_size()?
_M_check_len contains a path (hopefully not taken, but gcc doesn't see that)
where it returns max_size(), and we allocate 8 times the return value of
_M_check_len. With optimizations, gcc thus sees a path where we allocate
8*max_size(), that is size_t(-1) rounded down to a multiple of 8.
---
By the way, looking at an optimized dump of _M_realloc_insert, it almost starts
with (_46 is the size):
if (_46 == 0)
goto <bb 23>; [34.00%]
else
goto <bb 3>; [66.00%]
<bb 3> [local count: 77922475]:
__len_51 = _46 * 2;
if (_46 > __len_51)
goto <bb 22>; [53.03%]
else
goto <bb 4>; [46.97%]
<bb 4> [local count: 36599951]:
if (__len_51 > 2305843009213693951)
goto <bb 22>; [73.39%]
else
goto <bb 5>; [26.61%]
<bb 5> [local count: 9724245]:
if (__len_51 != 0)
The tests _46 > __len_51 and __len_51 > 2305843009213693951 both check if the
size is small enough, while the checks _46 == 0 and __len_51 != 0 both check if
the size is 0. That's a bit too much redundancy for error-checking code on the
hot path (I am not saying if that's the responsibility of the middle-end to
optimize it, or of libstdc++ not to have it in the first place).
