Re: [PATCH] Help compiler detect invalid code

[Jonathan Wakely <jwakely@redhat.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.