This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR c++/39480 not really fixed


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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]