On 11/11/10 10:56, Jed Brown wrote:
Unfortunately, I don't have a test case I can send; an actual
problem only manifested itself when running one of our commericial
applications on a fresh F14 install (dual Xeon E5620).
Do you happen to have a test case? I am running glibc-2.12.1
on 64-bit Arch Linux and although valgrind reports the
overlapping memcpy, I have not yet noticed incorrect results or
However as commented here:
https://bugzilla.redhat.com/show_bug.cgi?id=638477#c86 the valgrind
memcpy implementation is overlap-safe.
Are you using an Intel Nehalem-class CPU? The bug was also only
temperamental for me; I'm not entirely sure why. It would hang in
unmatched collectives 60-80% of the times run. With a forward
memcpy, it never hung.
I can provide a thought test case. Consider source and destination
where destination is 1 byte before source:
Copy forward memcpy:
Copy backward memcpy:
DST: DDDD (WRONG)