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

[Jonathan Wakely <jwakely at redhat dot com>]

On 25/02/20 16:01 +0200, Ville Voutilainen wrote:
> On Tue, 25 Feb 2020 at 15:36, Jonathan Wakely <jwakely@redhat.com> wrote:
> > 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.
>
> Looks good to me.


I've committed it now.

It's not strictly a regression, because the bug only happens when
using std::copy_backwards in a constant expression, which never
compiled before GCC 10 anyway. But enabling it to be used in constant
expressions but with incorrect results doesn't seem useful.