Re: [PATCH 0/6] m68k: merge and clean up files in m68k/lib

[Andreas Schwab <schwab@linux-m68k.org>]

Greg Ungerer <gerg@snapgear.com> writes:

> That does seem odd. One way or another strcpy is defined in
> arch/m68k/include/asm/string.h. I would expect no real calls to
> strcpy() after that. (And for me on my hand built gcc-4.5.1 I
> don't end up with any).

Did you compile with -Os?

> At a guess the section for __GNUC__ > 4 must end up still trying
> to use a real strcpy (presumably the __builtom_strcpy call) on
> some versions of gcc.
>
> #if __GNUC__ >= 4
> #define strcpy(d, s)    (__builtin_constant_p(s) &&     \
>                          __builtin_strlen(s) <= 32 ?    \
>                          __builtin_strcpy(d, s) :       \
>                          __kernel_strcpy(d, s))
> #else
> #define strcpy(d, s)    __kernel_strcpy(d, s)
> #endif
>
> Is there any reason we don't just drop the __GNUC__ >= 4 bit
> and always just use __kernel_strcpy()?  After all kernel_strcpy
> is a pretty tight optimized loop for m68k anyway.

The compiler can generate libcalls to strcpy any time while optimizing
any other standard C function, and those libcalls won't see the macros,
of course.  The only way to stop the compiler from doing that is to
disable all builtin functions (just -fno-builtin-strcpy is not enough),
but that would disable a lot of useful opimisations.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."