On Wed, Jun 9, 2021 at 12:10 PM Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > > > On 6/3/2021 12:51 PM, Seija K. via Gcc-patches wrote: > > This patch optimizes and simplifies many of the standard string functions. > > > > Since C99, some of the standard string functions have been changed to use > > the restrict modifier. > > > > diff --git a/libgcc/memcmp.c b/libgcc/memcmp.c > > index 2348afe1d27f7..74195cf6baf13 100644 > > --- a/libgcc/memcmp.c > > +++ b/libgcc/memcmp.c > > @@ -7,10 +7,11 @@ memcmp (const void *str1, const void *str2, size_t count) > > const unsigned char *s1 = str1; > > const unsigned char *s2 = str2; > > > > - while (count-- > 0) > > + while (count--) > > { > > - if (*s1++ != *s2++) > > - return s1[-1] < s2[-1] ? -1 : 1; > > + if (*s1 != *s2) > > + return *s1 < *s2 ? -1 : 1; > > + s1++, s2++; > > } > > return 0; > > } > I don't see the point behind this change and the similar ones in other > files. I'd like to see some justification for the change beyond just > "this looks cleaner to me". > > > > > > > diff --git a/libgcc/memcpy.c b/libgcc/memcpy.c > > index 58b1e405627aa..616df78fd2969 100644 > > --- a/libgcc/memcpy.c > > +++ b/libgcc/memcpy.c > > @@ -2,7 +2,7 @@ > > #include <stddef.h> > > > > void * > > -memcpy (void *dest, const void *src, size_t len) > > +memcpy (void * restrict dest, const void * restrict src, size_t len) > I would expect prototype fixes like this within libgcc to be reasonably > safe. > > > diff --git a/libiberty/memcpy.c b/libiberty/memcpy.c > > index 7f67d0bd1f26c..d388ae7f3506b 100644 > > --- a/libiberty/memcpy.c > > +++ b/libiberty/memcpy.c > > @@ -19,7 +19,7 @@ Copies @var{length} bytes from memory region > > @var{in} to region > > void bcopy (const void*, void*, size_t); > > > > PTR > > -memcpy (PTR out, const PTR in, size_t length) > > +memcpy (PTR restrict out, const PTR restrict in, size_t length) > It's not entirely clear that using "restrict" is safe because libiberty > is used by so many other projects which may be building with old > compilers, non-gcc compilers, etc. > > Generally the way to handle this is to use an autoconf check to confirm > that the tools can handle the feature you want to use and ensure there's > a fallback when they can't. >
The macro that autoconf provides for this purpose is AC_C_RESTRICT; it's documented here: https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/html_node/C-Compiler.html ...and defined here: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=lib/autoconf/c.m4;h=47434c89845e1a3f6b579cdac81aae5f27809daa;hb=HEAD#l2030 > Jeff