https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90436
--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
// possibly assumes that ptrdiff_t and size_t have the same size
size_type
_M_check_len_one(const char* __str) const
{
ptrdiff_t __n = sizeof(_Tp);
ptrdiff_t __ms = max_size(); __ms *= sizeof(_Tp);
ptrdiff_t __s = size(); __s *= sizeof(_Tp);
if (__s > (__ms - __n))
__throw_length_error(__N(__str));
const ptrdiff_t __len = __s + (std::max)(__s, __n);
if (__len <= 0) __builtin_unreachable();
ptrdiff_t __ret = (std::min)(__len, __ms);
return (_Tp*)__ret-(_Tp*)0; // hack to generate divexact, so it
simplifies with * sizeof(_Tp)
}
generates nicer code. But after those experiments, it seems clear that the
performance of this code is irrelevant (not surprising since it is followed by
a call to operator new), and its effect on global performance is random.
Possibly it causes something to get aligned differently, which can randomly get
this 25% speed-up, but can just as randomly go back to the slow version.
Anyway, I don't think I'll be submitting any patch for this.
