[committed] libstdc++: Fix regression in std::move algorithm (PR 93872)

[François Dumont]

I really like this patch but it has a little drawback related to my 
proposal:
https://gcc.gnu.org/ml/libstdc++/2019-10/msg00072.html

Now to make this code less defensive and so allow the compiler to report 
itself invalid usages in constexpr without the _GLIBCXX_DEBUG help we 
will have to change existing code, not some constexpr specific one.

François

On 2/25/20 2:36 PM, Jonathan Wakely wrote:
> On 25/02/20 12:40 +0000, Jonathan Wakely wrote:
>> The std::move and std::move_backward algorithms dispatch to the
>> std::__memmove helper when appropriate. That function uses a
>> pointer-to-const for the source values, preventing them from being
>> moved. The two callers of that function have the same problem.
>>
>> Rather than altering __memmove and its callers to work with const or
>> non-const source pointers, this takes a more conservative approach of
>> casting away the const at the point where we want to do a move
>> assignment. This relies on the fact that we only use __memmove when the
>> type is trivially copyable, so we know the move assignment doesn't alter
>> the source anyway.
>>
>> Â Â Â Â PR libstdc++/93872
>> Â Â Â Â * include/bits/stl_algobase.h (__memmove): Cast away const before
>> Â Â Â Â doing move assignment.
>> Â Â Â Â * testsuite/25_algorithms/move/93872.cc: New test.
>> Â Â Â Â * testsuite/25_algorithms/move_backward/93872.cc: New test.
>
> I think what I'd really like to do is get rid of __memmove entirely.
> We already have code that does the explicit assignment in a loop, for
> the cases where we can't use __builtin_memmove because the type is not
> trivially copyable.
>
> We should just use that existing code during constant evaluation, i.e.
> don't do the __builtin_memmove optimizations during constant
> evaluation. It seems much cleaner to just not use the optimization
> rather than wrap it to be usable in constant expressions.
>
> We already have to do that for {copy,move}_backward anyway, because
> __memmove doesn't correctly implement the std::memmove semantics for
> overlapping ranges. But we do it **wrong** and turn copy_backward into
> move_backward during constant evaluation.
>
> Here's a patch that gets rid of __memmove and fixes that bug
> (generated with 'git diff -b' so that the changes to the logic aren't
> obscured by the whitespace changes caused by re-indenting).
>
> Maybe I should just go ahead and do this now, since __memmove (and the
> problems it causes) are new for GCC 10 anyway. That would revert
> <bits/stl_algobase.h> to something closer to the GCC 9 version.
>
>