|
From: Konstantin S. <kon...@gm...> - 2009-05-06 08:23:34
|
On Wed, May 6, 2009 at 12:24 PM, Julian Seward <js...@ac...> wrote: > On Tuesday 05 May 2009, Nicholas Nethercote wrote: >> On Tue, May 5, 2009 at 5:03 AM, Konstantin Serebryany >> >> <kon...@gm...> wrote: >> > When copying structures of size 5, g++ (4.3.1) generates memcpy(dst, src, >> > 5). It may happen that src==dst (see example below). >> > src==dst is not allowed by the standard, but this code is not written >> > by humans and the compiler knows it is correct >> > (I asume that glibc will not explode with src==dst) >> > >> > Memcheck reports a warning. >> > >> > Even if this is a bug in gcc (is it?) we still need to workaround it >> > in memcheck. >> > Comments? >> >> These ones are always tricky, where the language spec doesn't match >> what happens in practice. This case is particularly annoying because >> we can't distinguish between a user-inserted memcpy() and a >> GCC-generated one. It's arguably that GCC shouldn't generate such >> code -- you say you assume glibc will not explode in this case, but >> that is an assumption. > > I think you should file this as a gcc bug. Yea, probably. But we still need a workaround in Memcheck. The existing versions of gcc will be there for years... --kcc > > AIUI, POSIX says the src==dst case is not allowed (along with all other > overlapping cases) because (eg) on PowerPC, it is possible to make a high > performance memcpy that preallocates the destination area in D1 using > dcbz instructions, which create the line in D1 and fill it full of > zeroes. This avoids dragging the destination line up the memory > hierarchy only to completely overwrite it with stuff from the source. > > Result is however that if the src and dst overlap, in any way, including > completely, then this causes zeroes to be written into the src area (!) > which is certainly not what you want. > > J > |