On Fri, Oct 28, 2011 at 12:54 PM, David Miller <da...@davemloft.net> wrote: > From: Richard Guenther <richard.guent...@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.
