|
From: <sv...@va...> - 2007-01-16 21:42:34
|
Author: sewardj Date: 2007-01-16 21:42:28 +0000 (Tue, 16 Jan 2007) New Revision: 6526 Log: Intercept _intel_fast_memcpy in the main executable. Partial fix for #139667. Modified: trunk/memcheck/mc_replace_strmem.c Modified: trunk/memcheck/mc_replace_strmem.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/memcheck/mc_replace_strmem.c 2007-01-16 20:01:15 UTC (rev 6525) +++ trunk/memcheck/mc_replace_strmem.c 2007-01-16 21:42:28 UTC (rev 6526) @@ -401,6 +401,15 @@ =20 MEMCPY(m_libc_soname, memcpy) MEMCPY(m_ld_so_1, memcpy) /* ld.so.1 */ +/* icc9 blats these around all over the place. Not only in the main + executable but various .so's. They are highly tuned and read + memory beyond the source boundary (although work correctly and + never go across page boundaries), so give errors when run natively, + at least for misaligned source arg. Just intercepting in the exe + only until we understand more about the problem. See + http://bugs.kde.org/show_bug.cgi?id=3D139776 + */ +MEMCPY(NONE, _intel_fast_memcpy) =20 =20 #define MEMCMP(soname, fnname) \ |