https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101542
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Brooks Moses from comment #0) > This started failing with a recent Clang change > (https://github.com/llvm/llvm-project/commit/ > 7d2d5a3a6d7aaa40468c30250bf6b0938ef02c08), described as "Apply P1825 as > Defect Report from C++11 up to C++20". See > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1825r0.html for the > defect report details. I would guess that GCC will be applying a similar > change. GCC 11 already implemented that, see PR 91427 and the commit https://gcc.gnu.org/g:1722e2013f05f1f1f99379dbaa0c0df356da731f The for that commit says: Discussion on the CWG reflector about how to avoid breaking the PR91212 test in the new model settled on the model of doing only a single overload resolution, with the variable treated as an xvalue that can bind to non-const lvalue references. So this patch implements that approach. The implementation does not use the existing LOOKUP_PREFER_RVALUE flag, but instead sets a flag on the representation of the static_cast turning the variable into an xvalue. which says that calling sequence_buffer(sequence_buffer&) here is intended, which is why we didn't see any change in the ext/rope/4.cc test when GCC implemented it. I still think we want to make sequence_buffer move-aware, so that you get the same behaviour for: template<typename T> T f(T x) { return x; } template<typename T> T g(T x) { return std::move(x); } when passed a sequence_buffer.
