This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Revert commit 05a910f7
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Cc: nd <nd at arm dot com>
- Date: Mon, 7 Mar 2016 23:20:48 +0000
- Subject: Re: [PATCH] Revert commit 05a910f7
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <CAMe9rOrYywzUwdCmsG06ppzdKC9Gntwhia_kMp25ETTx+weDpQ at mail dot gmail dot com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
H.J. Lu <hjl.tools@gmail.com> wrote:
>> +/* Don't inline mempcpy into memcpy as x86 has an optimized mempcpy. */
>> +# define _HAVE_STRING_ARCH_mempcpy 1
>> +
>> /* Copy N bytes of SRC to DEST. */
>> # define _HAVE_STRING_ARCH_memcpy 1
>> # define memcpy(dest, src, n) \
>> --
>> 2.5.0
>>
>
> It doesn't work since <bits/string.h> is included only if
>
> #if defined __GNUC__ && __GNUC__ >= 2
> # if defined __OPTIMIZE__ && !defined __OPTIMIZE_SIZE__ \
> && !defined __NO_INLINE__ && !defined __cplusplus
>
> is true.
>
> I believe commit 05a910f7 was wrong. At minimum,
> mempcpy shouldn't be inlined in 2 different header files.
There is nothing wrong with that commit. I already posted patches that remove most
of the redundant stuff from bits/string.h, including the duplicate mempcpy defines.
I don't understand how defining _HAVE_STRING_ARCH_mempcpy doesn't work for you
either, unless you use non-standard options or a very ancient compiler.
The proper solution is to get rid of the bits/string.h mess altogether rather than
conditionally including it. With my outstanding patches we're there most of the way.
Wilco