From: Julian Seward <jseward@acm.org>
Date: Tue, 16 Jan 2007 22:04:50 +0000 (+0000)
Subject: Merge r6526 (Intercept _intel_fast_memcpy in the main executable.)
X-Git-Tag: svn/VALGRIND_3_2_2~10
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=ffaca718ae8ae3a9323aaaa16af2eaf99d244cfb;p=thirdparty%2Fvalgrind.git

Merge r6526 (Intercept _intel_fast_memcpy in the main executable.)


git-svn-id: svn://svn.valgrind.org/valgrind/branches/VALGRIND_3_2_BRANCH@6528
---

diff --git a/memcheck/mc_replace_strmem.c b/memcheck/mc_replace_strmem.c
index a3d2850640..3fb1792580 100644
--- a/memcheck/mc_replace_strmem.c
+++ b/memcheck/mc_replace_strmem.c
@@ -406,6 +406,16 @@ MEMCHR(m_libc_so_star, memchr)
 MEMCPY(m_libc_so_star, 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=139776
+ */
+MEMCPY(NONE, _intel_fast_memcpy)
+
 
 #define MEMCMP(soname, fnname) \
    int VG_REPLACE_FUNCTION_ZU(soname,fnname) \