https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102221
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2021-09-08
Ever confirmed|0 |1
Keywords| |missed-optimization
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This comes from the construction of a local unique_ptr<int> variable in:
template<typename _RandomAccessIterator, typename _Compare>
_GLIBCXX20_CONSTEXPR
void
__unguarded_linear_insert(_RandomAccessIterator __last,
_Compare __comp)
{
typename iterator_traits<_RandomAccessIterator>::value_type
__val = _GLIBCXX_MOVE(*__last);
_RandomAccessIterator __next = __last;
--__next;
while (__comp(__val, __next))
{
*__last = _GLIBCXX_MOVE(*__next);
__last = __next;
--__next;
}
*__last = _GLIBCXX_MOVE(__val);
}
The compiler apparently doesn't see that after std::move(__val) on the last
line there is no need to invoke the deleter, because it's empty.
The use of std::tuple<int*, default_delete<int>> for std::unique_ptr might make
it too hard for the compiler to track the value of the stored pointer.
I'm not sure there's anything the library can do here (except maybe replace
std::tuple with [[no_unique_address]], once all the compilers we care about
support that properly).
