This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PR c++/39480 not really fixed
On Fri, Oct 28, 2011 at 12:54 PM, David Miller <davem@davemloft.net> wrote:
> From: Richard Guenther <richard.guenther@gmail.com>
> Date: Fri, 28 Oct 2011 12:47:30 +0200
>
>> Then we have to fix the middle-end which will happily expand
>> block-moves to memcpy with exact overlap (a = a is valid in C).
>> See the PR and the C testcases therein.
>>
>> Just trying to avoid this in the C++ frontend is bogus.
>
> Agreed.
>
>> Of course, as Linus would say, such implementation would be "broken" ;)
>> (I expect that such implementations can (and would) easily avoid the situation
>> with almost no cost by doing an early out for src == dst).
>
> memcpy is not required to be mindful of overlapping buffers.
>
> Otherwise there is no point in having seperate memmove() and memcpy()
> interfaces in the first place.
Sure - we are only talking about _exact_ overlap (src == dst), not partial
overlap. GCC at the moment requires the memcpy implementation
to handle src == dest fine (and it will never emit a memcpy call
for valid C source for partially overlapping src and dst).
> Even internally inside of GCC there is confusion about the movmem
> patterns. ?The documentation explicitly states that movmem need not
> give special consideration to the posibility that source and
> destination might overlap.
>
> But the comments about the expander in the MIPS backend mention that
> they might overlap.
>
> And reality shows that the middle-end will end up expanding such
> overlapping cases.
Only with exact overlap.
Richard.