Re: [PATCH] Help compiler detect invalid code

[Jonathan Wakely <jwakely at redhat dot com>]

On 01/10/19 22:05 +0200, François Dumont wrote:
> On 9/27/19 1:24 PM, Jonathan Wakely wrote:
> > On 20/09/19 07:08 +0200, François Dumont wrote:
> > > I already realized that previous patch will be too controversial 
> > > to be accepted.
> > >
> > > In this new version I just implement a real memmove in __memmove 
> > > so
> >
> > A real memmove doesn't just work backwards, it needs to detect any
> > overlaps and work forwards *or* backwards, as needed.
> ok, good to know, I understand now why using __builtin_memcopy didn't 
> show any performance enhancement when I tested it !
> > I think your change will break this case:
> >
> > #include <algorithm>
> >
> > constexpr int f(int i, int j, int k)
> > {
> >  int arr[5] = { 0, 0, i, j, k };
> >  std::move(arr+2, arr+5, arr);
> >  return arr[0] + arr[1] + arr[2];
> > }
> >
> > static_assert( f(1, 2, 3) == 6 );
> >
> > This is valid because std::move only requires that the result iterator
> > is not in the input range, but it's OK for the two ranges to overlap.
> >
> > I haven't tested it, but I think with your change the array will end
> > up containing {3, 2, 3, 2, 3} instead of {1, 2, 3, 2, 3}.
> Indeed, I've added a std::move constexpr test in this new proposal 
> which demonstrate that.
>
> C++ Standard clearly states that [copy|move]_backward is done 
> backward. So in this new proposal I propose to add a __memcopy used in 
> copy/move and keep __memmove for *_backward algos. Both are using 
> __builtin_memmove as before.

Then they *really* need better names now (__memmove was already a bad
name, but now it's terrible). If the difference is that one goes
forwards and one goes backwards, the names should reflect that.

I'll review it properly tomorrow.