Comment 78 for bug 727064

(In reply to comment #29)
> Looking at the changelog for glibc-2.12.90-4 shows:
>
> * Fri Jul 02 2010 Andreas Schwab <email address hidden> - 2.12.90-4
> [...]
> - Improve 64bit memcpy/memmove for Atom, Core 2 and Core i7
> [...]
> I used chromium to run valgrind on the flash plugin [...]
> ==2100== Thread 9:
> ==2100== Source and destination overlap in memcpy(0x256d7170, 0x256d7570, 1280)
> ==2100== at 0x4A06A3A: memcpy (mc_replace_strmem.c:497)

That does look like a very possible smoking gun.

Normally, a memcpy that copies _downwards_ (like the one above) will work
perfectly well in practice, because the "natural" way to do memcpy() by making
it just copy things upwards will "just work" even for the overlapping case.

So it would be a bug to use memcpy for overlapping areas, but it would be a
bug that normally would never show up.

But if the new improved 64bit memcpy started copying things backwards, it might
cause trouble with such an overlapping memcpy user.

[ That said - why the heck would you ever do memcpy() backwards? Things like
  automatic prefetchers usually work better for the "natural" patterns, so a
  backwards memcpy is generally a bad thing to do unless you have some active
  reason for it, like doing a memmove() ]

> On a related note, is there a glibc environment flag that can be set to force a
> generic memcpy routine to run?

Indeed, that would be very interesting to see.

Andreas?