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

Jonathan Wakely jwakely@redhat.com
Tue Feb 25 13:36:00 GMT 2020


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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 6794 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20200225/bd6ec259/attachment.bin>


More information about the Libstdc++ mailing list