Don't use __warn_memset_zero_len for gcc-5.0 or newer

gcc now warns when the arguments to memset may have been accidentally
transposed (i.e. length set to zero instead of the byte), so we don't
need that bit of the code in glibc headers anymore.

Tested on x86_64.  Coe generated by gcc 4.8 is identical with or
without the patch.  I also tested gcc master, which does not result in
any new failures.  It does fail quite a few FORTIFY_SOURCE tests, but
those failures are not due to this patch.

1 files changed, 6 insertions, 0 deletions

diff --git a/string/bits/string3.h b/string/bits/string3.h
index 760609033a..801e7aca24 100644
--- a/string/bits/string3.h
+++ b/string/bits/string3.h
@@ -19,8 +19,10 @@
 # error "Never use <bits/string3.h> directly; include <string.h> instead."
 #endif
 
+#if !__GNUC_PREREQ (5,0)
 __warndecl (__warn_memset_zero_len,
 	    "memset used with constant zero length parameter; this could be due to transposed parameters");
+#endif
 
 #ifndef __cplusplus
 /* XXX This is temporarily.  We should not redefine any of the symbols
@@ -75,12 +77,16 @@ __NTH (mempcpy (void *__restrict __dest, const void *__restrict __src,
 __fortify_function void *
 __NTH (memset (void *__dest, int __ch, size_t __len))
 {
+  /* GCC-5.0 and newer implements these checks in the compiler, so we don't
+     need them here.  */
+#if !__GNUC_PREREQ (5,0)
   if (__builtin_constant_p (__len) && __len == 0
       && (!__builtin_constant_p (__ch) || __ch != 0))
     {
       __warn_memset_zero_len ();
       return __dest;
     }
+#endif
   return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
 }