Bug 16458 reports that the endian-conversion macros in <endian.h> and
<netinet/in.h>, in the case where no endian conversion is needed, just
return their arguments without converting to the expected return type,
so failing to act as expected for a macro version of a function. (The
<netinet/in.h> macros, in particular, are described with prototypes in
POSIX so should act like correspondingly prototyped functions.)
Where previously this was a fairly obscure issue, it now results in
glibc build with GCC mainline breaking for big-endian systems:
nss_hesiod/hesiod-service.c: In function '_nss_hesiod_getservbyport_r':
nss_hesiod/hesiod-service.c:142:39: error: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size 6 [-Werror=format-truncation=]
snprintf (portstr, sizeof portstr, "%d", ntohs (port));
^~
nss_hesiod/hesiod-service.c:142:38: note: using the range [1, -2147483648] for directive argument
snprintf (portstr, sizeof portstr, "%d", ntohs (port));
^~~~
nss_hesiod/hesiod-service.c:142:3: note: format output between 2 and 12 bytes into a destination of size 6
snprintf (portstr, sizeof portstr, "%d", ntohs (port));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The port argument is passed as int to this function, so when ntohs
does not convert the compiler cannot tell that the result is within
the range of uint16_t. (I don't know if in fact it's possible for
out-of-range values to reach this function and so get truncated as
strings without this patch or as integers with it.)
This patch arranges for these macros to use identity functions to
ensure appropriate conversions while having warnings for implicit
conversions of function arguments that might not occur with a cast.
Tested for x86_64 and x86; with build-many-glibcs.py with GCC 6; and
with build-many-glibcs.py with GCC mainline for powerpc to test the
build fix.
[BZ #16458]
* bits/uintn-identity.h: New file.
* inet/netinet/in.h: Include <bits/uintn-identity.h>.
[__BYTE_ORDER == __BIG_ENDIAN] (ntohl): Use __uint32_identity.
[__BYTE_ORDER == __BIG_ENDIAN] (ntohs): Use __uint16_identity.
[__BYTE_ORDER == __BIG_ENDIAN] (htonl): Use __uint32_identity.
[__BYTE_ORDER == __BIG_ENDIAN] (htohs): Use __uint16_identity.
* string/endian.h: Include <bits/uintn-identity.h>.
[__BYTE_ORDER == __LITTLE_ENDIAN] (htole16): Use
__uint16_identity.
[__BYTE_ORDER == __LITTLE_ENDIAN] (le16toh): Likewise.
[__BYTE_ORDER == __LITTLE_ENDIAN] (htole32): Use
__uint32_identity.
[__BYTE_ORDER == __LITTLE_ENDIAN] (le32toh): Likewise.
[__BYTE_ORDER == __LITTLE_ENDIAN] (htole64): Use
__uint64_identity.
[__BYTE_ORDER == __LITTLE_ENDIAN] (le64toh): Likewise.
[__BYTE_ORDER != __LITTLE_ENDIAN] (htobe16): Use
__uint16_identity.
[__BYTE_ORDER != __LITTLE_ENDIAN] (be16toh): Likewise.
[__BYTE_ORDER != __LITTLE_ENDIAN] (htobe32): Use
__uint32_identity.
[__BYTE_ORDER != __LITTLE_ENDIAN] (be32toh): Likewise.
[__BYTE_ORDER != __LITTLE_ENDIAN] (htobe64): Use
__uint64_identity.
[__BYTE_ORDER != __LITTLE_ENDIAN] (be64toh): Likewise.
* string/Makefile (headers): Add bits/uintn-identity.h.
(tests): Add test-endian-types.
* string/test-endian-types.c: New file.
* inet/Makefile (tests): Add test-hnto-types.
* inet/test-hnto-types.c: New file.
Commit 38765ab68f moved the bzero, bcopy, and explicit_bzero
fortified macros to a common header (strings_fortified.h). However
the side effect is a fortified explicit_bzero is defined when including
only strings.h.
This patch moves back the fortified explicit_bzero definition to
strings3.h header.
Checked on x86_64-linux-gnu.
* string/bits/strings_fortified.h (explicit_bzero): Move back to ..
* string/bits/string3.h: ... here.
As described in BZ#20558, bzero and bcopy declaration can only benefit
from fortified macros when decl came from string.h and when __USE_MISC
is defined (default behaviour).
This is due no standard includes those functions in string.h, so they
are only declared if __USE_MISC is defined (as pointed out in comment 4).
However fortification should be orthogona to other features test macros,
i.e, any function should be fortified if that function is declared.
To fix this behavior, the patch moved the bzero, bcopy, and
__explicit_bzero_chk to a common header (string/bits/strings_fortified.h)
and explicit fortified inclusion macros similar to string.h is added
on strings.h. This allows to get fortified declarions by only including
strings.h.
Checked on x86_64-linux-gnu and along on a bootstrap installation to check
if the fortified are correctly triggered with example from bug report.
[BZ #20558]
* string/bits/string3.h [__USE_MISC] (bcopy): Move to
strings_fortified.h.
[__USE_MISC] (bzero): Likewise.
[__USE_MISC] (explicit_bzero): Likewise.
* string/strings.h: Include strings_fortified.h.
* string/Makefile (headers): Add strings_fortified.h.
* string/bits/strings_fortified.h: New file.
* include/bits/strings_fortified.h: Likewise.
GCC 7 has a -Wstringop-overflow= warning that includes warning for
strncat with a size specified that is larger than the size of the
buffer (which is dubious usage, but valid at runtime if in fact there
isn't an overflow with the particular buffer contents present).
string/tester.c tests such cases; this patch arranges for this warning
to be ignored around relevant strncat calls.
Tested compilation for aarch64 (GCC mainline) with
build-many-glibcs.py; did execution testing for x86_64 (GCC 5).
* string/tester.c (test_strncat): Disable -Wstringop-overflow=
around tests of strncat with large sizes.
Similar to BZ#19387, BZ#21014, and BZ#20971, both x86 sse2 strncat
optimized assembly implementations do not handle the size overflow
correctly.
The x86_64 one is in fact an issue with strcpy-sse2-unaligned, but
that is triggered also with strncat optimized implementation.
This patch uses a similar strategy used on 3daef2c8ee, where
saturared math is used for overflow case.
Checked on x86_64-linux-gnu and i686-linux-gnu. It fixes BZ #19390.
[BZ #19390]
* string/test-strncat.c (test_main): Add tests with SIZE_MAX as
maximum string size.
* sysdeps/i386/i686/multiarch/strcat-sse2.S (STRCAT): Avoid overflow
in pointer addition.
* sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S (STRCPY):
Likewise.
Current optimized memchr for x86_64 does for input arguments pointers
module 64 in range of [49,63] if there is no searchr char in the rest
of 64-byte block a pointer addition which might overflow:
* sysdeps/x86_64/memchr.S
77 .p2align 4
78 L(unaligned_no_match):
79 add %rcx, %rdx
Add (uintptr_t)s % 16 to n in %rdx.
80 sub $16, %rdx
81 jbe L(return_null)
This patch fixes by adding a saturated math that sets a maximum pointer
value if it overflows (UINTPTR_MAX).
Checked on x86_64-linux-gnu and powerpc64-linux-gnu.
[BZ# 19387]
* sysdeps/x86_64/memchr.S (memchr): Avoid overflow in pointer
addition.
* string/test-memchr.c (do_test): Remove alignment limitation.
(test_main): Add test that trigger BZ# 19387.
The startup code in csu/, and the brk and sbrk functions are
needed very early in initialization of a statically-linked program,
before the stack guard is initialized; TLS initialization also uses
memcpy, which cannot overrun its own stack. Mark all of these as
-fno-stack-protector.
We also finally introduce @libc_cv_ssp@ and @no_stack_protector@, both
substituted by the configury changes made earlier, to detect the case
when -fno-stack-protector is supported by the compiler, and
unconditionally pass it in when this is the case, whether or not
--enable-stack-protector is passed to configure. (This means that
it'll even work when the compiler's been hacked to pass
-fstack-protector by default, unless the hackage is so broken that
it does so in a way that is impossible to override.)
Currently strsep calls strpbrk is is now a veneer to strcspn. Calling
strcspn directly is faster. Since it handles a delimiter string of size
1 as a special case, this is not needed in strsep itself. Although this
means there is a slightly higher overhead if the delimiter size is 1,
all other cases are slightly faster. The overall performance gain is 5-10%
on AArch64.
The string/bits/string2.h header contains optimizations for constant
delimiters of size 1-3. Benchmarking these showed similar performance for
size 1 (since in all cases strchr/strchrnul is used), while size 2 and 3
can give up to 2x speedup for small input strings. However if these cases
are common it seems much better to add this optimization to strcspn.
So move these header optimizations to string-inlines.c.
Improve the strsep benchmark so that it actually benchmarks something.
The current version contains a delimiter character at every position in the
input string, so there is very little work to do, and the extremely inefficent
simple_strsep implementation appears fastest in every case. The new version
has either no match in the input for the fail case and a match halfway in the
input for the success case. The input is then restored so that each iteration
does exactly the same amount of work. Reduce the number of testcases since
simple_strsep takes a lot of time now.
* benchtests/bench-strsep.c (oldstrsep): Add old implementation.
(do_one_test) Restore original string so iteration works.
* string/string-inlines.c (do_test): Create better input strings.
(test_main) Reduce number of testruns.
* string/string-inlines.c (__old_strsep_1c): New function.
(__old_strsep_2c): Likewise.
(__old_strsep_3c): Likewise.
* string/strsep.c (__strsep): Remove case of small delim string.
Call strcspn directly rather than strpbrk.
* string/bits/string2.h (__strsep): Remove define.
(__strsep_1c): Remove.
(__strsep_2c): Remove.
(__strsep_3c): Remove.
(strsep): Remove.
* sysdeps/unix/sysv/linux/internal_statvfs.c
(__statvfs_getflags): Rename to __strsep.
Some targets fail to apply dead store elimination to the
memset call in setup_ordinary_clear. Before this commit,
this causes the test case to fail. Instead, the test case
now logs lack of memset elimination as an informational
message.
explicit_bzero(s, n) is the same as memset(s, 0, n), except that the
compiler is not allowed to delete a call to explicit_bzero even if the
memory pointed to by 's' is dead after the call. Right now, this effect
is achieved externally by having explicit_bzero be a function whose
semantics are unknown to the compiler, and internally, with a no-op
asm statement that clobbers memory. This does mean that small
explicit_bzero operations cannot be expanded inline as small memset
operations can, but on the other hand, small memset operations do get
deleted by the compiler. Hopefully full compiler support for
explicit_bzero will happen relatively soon.
There are two new tests: test-explicit_bzero.c verifies the
visible semantics in the same way as the existing test-bzero.c,
and tst-xbzero-opt.c verifies the not-being-optimized-out property.
The latter is conceptually based on a test written by Matthew Dempsky
for the OpenBSD regression suite.
The crypt() implementation has an immediate use for this new feature.
We avoid having to add a GLIBC_PRIVATE alias for explicit_bzero
by running all of libcrypt's calls through the fortified variant,
__explicit_bzero_chk, which is in the impl namespace anyway. Currently
I'm not aware of anything in libc proper that needs this, but the
glue is all in place if it does become necessary. The legacy DES
implementation wasn't bothering to clear its buffers, so I added that,
mostly for consistency's sake.
* string/explicit_bzero.c: New routine.
* string/test-explicit_bzero.c, string/tst-xbzero-opt.c: New tests.
* string/Makefile (routines, strop-tests, tests): Add them.
* string/test-memset.c: Add ifdeffage for testing explicit_bzero.
* string/string.h [__USE_MISC]: Declare explicit_bzero.
* debug/explicit_bzero_chk.c: New routine.
* debug/Makefile (routines): Add it.
* debug/tst-chk1.c: Test fortification of explicit_bzero.
* string/bits/string3.h: Fortify explicit_bzero.
* manual/string.texi: Document explicit_bzero.
* NEWS: Mention addition of explicit_bzero.
* crypt/crypt-entry.c (__crypt_r): Clear key-dependent intermediate
data before returning, using explicit_bzero.
* crypt/md5-crypt.c (__md5_crypt_r): Likewise.
* crypt/sha256-crypt.c (__sha256_crypt_r): Likewise.
* crypt/sha512-crypt.c (__sha512_crypt_r): Likewise.
* include/string.h: Redirect internal uses of explicit_bzero
to __explicit_bzero_chk[_internal].
* string/Versions [GLIBC_2.25]: Add explicit_bzero.
* debug/Versions [GLIBC_2.25]: Add __explicit_bzero_chk.
* sysdeps/arm/nacl/libc.abilist
* sysdeps/unix/sysv/linux/aarch64/libc.abilist
* sysdeps/unix/sysv/linux/alpha/libc.abilist
* sysdeps/unix/sysv/linux/arm/libc.abilist
* sysdeps/unix/sysv/linux/hppa/libc.abilist
* sysdeps/unix/sysv/linux/i386/libc.abilist
* sysdeps/unix/sysv/linux/ia64/libc.abilist
* sysdeps/unix/sysv/linux/m68k/coldfire/libc.abilist
* sysdeps/unix/sysv/linux/m68k/m680x0/libc.abilist
* sysdeps/unix/sysv/linux/microblaze/libc.abilist
* sysdeps/unix/sysv/linux/mips/mips32/fpu/libc.abilist
* sysdeps/unix/sysv/linux/mips/mips32/nofpu/libc.abilist
* sysdeps/unix/sysv/linux/mips/mips64/n32/libc.abilist
* sysdeps/unix/sysv/linux/mips/mips64/n64/libc.abilist
* sysdeps/unix/sysv/linux/nios2/libc.abilist
* sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu/libc.abilist
* sysdeps/unix/sysv/linux/powerpc/powerpc32/nofpu/libc.abilist
* sysdeps/unix/sysv/linux/powerpc/powerpc64/libc-le.abilist
* sysdeps/unix/sysv/linux/powerpc/powerpc64/libc.abilist
* sysdeps/unix/sysv/linux/s390/s390-32/libc.abilist
* sysdeps/unix/sysv/linux/s390/s390-64/libc.abilist
* sysdeps/unix/sysv/linux/sh/libc.abilist
* sysdeps/unix/sysv/linux/sparc/sparc32/libc.abilist
* sysdeps/unix/sysv/linux/sparc/sparc64/libc.abilist
* sysdeps/unix/sysv/linux/tile/tilegx/tilegx32/libc.abilist
* sysdeps/unix/sysv/linux/tile/tilegx/tilegx64/libc.abilist
* sysdeps/unix/sysv/linux/tile/tilepro/libc.abilist
* sysdeps/unix/sysv/linux/x86_64/64/libc.abilist
* sysdeps/unix/sysv/linux/x86_64/x32/libc.abilist:
Add entries for explicit_bzero and __explicit_bzero_chk.
Current optimized powercp64/power7 memchr uses a strategy to check for
p versus align(p+n) (where 'p' is the input char pointer and n the
maximum size to check for the byte) without taking care for possible
overflow on the pointer addition in case of large 'n'.
It was triggered by 3038145ca2 where default rawmemchr (used to
created ppc64 rawmemchr in ifunc selection) now uses memchr (p, c, (size_t)-1)
on its implementation.
This patch fixes it by implement a satured addition where overflows
sets the maximum pointer size to UINTPTR_MAX.
Checked on powerpc64le-linux-gnu.
[BZ# 20971]
* sysdeps/powerpc/powerpc64/power7/memchr.S (__memchr): Avoid
overflow in pointer addition.
* string/test-memchr.c (do_test): Add an argument to pass as
the size on memchr.
(test_main): Add check for SIZE_MAX.
calls strcspn, call strcspn directly so we get the end of the token without
an extra call to rawmemchr. Also avoid an unnecessary call to strcspn after
the last token by adding an early exit for an empty string. Change strtok
to tailcall strtok_r to avoid unnecessary code duplication.
Remove the special header optimization for strtok_r of a 1-character
constant string - both strspn and strcspn contain optimizations for this
case. Benchmarking this showed similar performance in the worst case,
but up to 5.5x better performance in the "found" case for large inputs.
* benchtests/bench-strtok.c (oldstrtok): Add old implementation.
* string/strtok.c (strtok): Change to tailcall __strtok_r.
* string/strtok_r.c (__strtok_r): Optimize for performance.
* string/string-inlines.c (__old_strtok_r_1c): New function.
* string/bits/string2.h (__strtok_r): Move to string-inlines.c.
assembler version by tailcalling memchr with the maximum size.
If a target has an optimized memchr this is significantly faster,
if not, then this makes little difference.
Also optimize the special case of zero to use strlen as this is
typically faster than memchr.
* string/rawmemchr.c (RAWMEMCHR): Use faster memchr/strlen.
The comment above the bzero() macro in this file appears to have been
copied verbatim from the comment above the memset() prototype in
string.h proper. bzero() has no 'c' argument and can only set memory
contents to 0. (The comment above the prototype of bzero() in
string.h proper does not make the same mistake.)
* string/bits/string2.h: Fix typo in comment.
This commit adds a new DIAG_IGNORE_Os_NEEDS_COMMENT which is only
enabled when compiling with -Os. This allows developers working on
-Os enabled builds to mark false-positive warnings without impacting the
warnings emitted at -O2.
Then using the new DIAG_IGNORE_Os_NEEDS_COMMENT we fix 6 warnings
generated with GCC 5 to get -Os builds working again.
The new check-installed-headers rule check now complains with C++
comment from string3.h with:
../string/bits/string3.h:129:1: error: C++ style comments are not allowed in ISO C90
// XXX We have no corresponding builtin yet.
Let use old C style comment to make compiler happy in old modes.
Tested on x86_64.
* string/bits/string3.h: Remove C++ style comments.
This patch implements support for the __STDC_WANT_LIB_EXT2__ feature
test macro from ISO/IEC TR 24731-2:2010, thereby implementing one
possible approach for supporting ISO C feature test macros.
Recall that, as described in
<https://sourceware.org/ml/libc-alpha/2016-05/msg00486.html>, these
macros work based on the definition when affected headers are
included, so cannot be handled once when the first system header is
included because that might not be one of the headers the particular
macro in question affects.
<https://sourceware.org/ml/libc-alpha/2016-05/msg00680.html> expresses
views on possible approaches for implementation and
<https://sourceware.org/ml/libc-alpha/2016-06/msg00039.html> follows
up on that.
This patch arranges things so that the relevant condition is
__GLIBC_USE (LIB_EXT2), following one of the suggestions given.
Headers using these macros include <bits/libc-header-start.h>, which
in turn includes <features.h>. Headers must define
__GLIBC_INTERNAL_STARTING_HEADER_IMPLEMENTATION before including
<bits/libc-header-start.h>, to discourage inclusion outside glibc as
requested. __USE_GNU conditions on affected functions are changed to
__GLIBC_USE (LIB_EXT2), while it's added as an additional alternative
on the conditions for functions already enabled for some POSIX
versions.
It would be possible to convert existing __USE_* conditionals to
__GLIBC_USE (with the relevant __GLIBC_USE_* being defined in
<features.h> where __USE_* are presently defined), and so make them
typo-proof (given -Wundef -Werror in glibc builds) because __GLIBC_USE
is used with #if not #ifdef / #if defined.
No attempt is made to enforce the rule about diagnosing different
definitions of __STDC_WANT_LIB_EXT2__ when affected headers are
included; such a diagnostic is incompatible with multiple-include
guards on the affected headers, unless compiler extensions are added
to support it.
As previously noted, glibc does not implement all features from TR
24731-2:2010: the functions aswprintf vaswprintf getwdelim getwline
are not in glibc, although they would be appropriate to add if someone
wished to do so. But I think it makes sense to support the feature
test macro if *any* of the controlled features are present in glibc.
Tested for x86_64 and x86 (testsuite, and that installed stripped
shared libraries are unchanged by the patch).
* bits/libc-header-start.h: New file.
* Makefile (headers): Add bits/libc-header-start.h.
* include/features.h (__STDC_WANT_LIB_EXT2__): Document.
(__GLIBC_USE): New macro.
* libio/stdio.h: Define
__GLIBC_INTERNAL_STARTING_HEADER_IMPLEMENTATION and include
<bits/libc-header-start.h> instead of including <features.h>.
(fmemopen): Declare also if [__GLIBC_USE (LIB_EXT2)].
(open_memstream): Likewise.
(vasprintf): Declare if [__GLIBC_USE (LIB_EXT2)], not [__USE_GNU].
(__asprintf): Likewise.
(asprintf): Likewise.
(__getdelim): Declare also if [__GLIBC_USE (LIB_EXT2)].
(getdelim): Likewise.
(getline): Likewise.
* string/string.h: Define
__GLIBC_INTERNAL_STARTING_HEADER_IMPLEMENTATION and include
<bits/libc-header-start.h> instead of including <features.h>.
(strdup): Declare also if [__GLIBC_USE (LIB_EXT2)]
(strndup): Likewise.
* wcsmbs/wchar.h: Define
__GLIBC_INTERNAL_STARTING_HEADER_IMPLEMENTATION and include
<bits/libc-header-start.h> instead of including <features.h>.
(open_wmemstream): Declare also if [__GLIBC_USE (LIB_EXT2)].
* manual/creature.texi (__STDC_WANT_LIB_EXT2__): Document macro.
Clear the destination buffer updated by the previous run in bench-memcpy.c
and test-memcpy.c to catch the error when the following implementations do
not copy anything.
[BZ #19907]
* benchtests/bench-memcpy.c (do_one_test): Clear the destination
buffer updated by the previous run.
* string/test-memcpy.c (do_one_test): Likewise.
* benchtests/bench-memmove.c (do_one_test): Add a comment.
* string/test-memmove.c (do_one_test): Likewise.
With now a faster strcspn implementation, it is faster to just use
it with some return tests than reimplementing strpbrk itself.
As for strcspn optimization, it is generally at least 10 times faster
than the existing implementation on bench-strspn on a few AArch64
implementations.
Also the string/bits/string2.h inlines make no longer sense, as current
implementation will already implement most of the optimizations.
Tested on x86_64, i386, and aarch64.
* string/strpbrk.c (strpbrk): Rewrite function.
* string/bits/string2.h (strpbrk): Use __builtin_strpbrk.
(__strpbrk_c2): Likewise.
(__strpbrk_c3): Likewise.
* string/string-inlines.c
[SHLIB_COMPAT(libc, GLIBC_2_1_1, GLIBC_2_24)] (__strpbrk_c2):
Likewise.
[SHLIB_COMPAT(libc, GLIBC_2_1_1, GLIBC_2_24)] (__strpbrk_c3):
Likewise.
As for strcspn, this patch improves strspn performance using a much
faster algorithm. It first constructs a 256-entry table based on
the accept string and then uses it as a lookup table for the
input string. As for strcspn optimization, it is generally at least
10 times faster than the existing implementation on bench-strspn
on a few AArch64 implementations.
Also the string/bits/string2.h inlines make no longer sense, as current
implementation will already implement most of the optimizations.
Tested on x86_64, i686, and aarch64.
* string/strspn.c (strcspn): Rewrite function.
* string/bits/string2.h (strspn): Use __builtin_strcspn.
(__strspn_c1): Remove inline function.
(__strspn_c2): Likewise.
(__strspn_c3): Likewise.
* string/string-inlines.c
[SHLIB_COMPAT(libc, GLIBC_2_1_1, GLIBC_2_24)] (__strspn_c1): Add
compatibility symbol.
[SHLIB_COMPAT(libc, GLIBC_2_1_1, GLIBC_2_24)] (__strspn_c2):
Likewise.
[SHLIB_COMPAT(libc, GLIBC_2_1_1, GLIBC_2_24)] (__strspn_c3):
Likewise.
Improve strcspn performance using a much faster algorithm. It is kept simple
so it works well on most targets. It is generally at least 10 times faster
than the existing implementation on bench-strcspn on a few AArch64
implementations, and for some tests 100 times as fast (repeatedly calling
strchr on a small string is extremely slow...).
In fact the string/bits/string2.h inlines make no longer sense, as GCC
already uses strlen if reject is an empty string, strchrnul is 5 times as
fast as __strcspn_c1, while __strcspn_c2 and __strcspn_c3 are slower than
the strcspn main loop for large strings (though reject length 2-4 could be
special cased in the future to gain even more performance).
Tested on x86_64, i686, and aarch64.
* string/Version (libc): Add GLIBC_2.24.
* string/strcspn.c (strcspn): Rewrite function.
* string/bits/string2.h (strcspn): Use __builtin_strcspn.
(__strcspn_c1): Remove inline function.
(__strcspn_c2): Likewise.
(__strcspn_c3): Likewise.
* string/string-inline.c
[SHLIB_COMPAT(libc, GLIBC_2_1_1, GLIBC_2_24)] (__strcspn_c1): Add
compatibility symbol.
[SHLIB_COMPAT(libc, GLIBC_2_1_1, GLIBC_2_24)] (__strcspn_c2):
Likewise.
[SHLIB_COMPAT(libc, GLIBC_2_1_1, GLIBC_2_24)] (__strcspn_c3):
Likewise.
* sysdeps/i386/string-inlines.c: Include generic string-inlines.c.
As discussed in
https://sourceware.org/ml/libc-alpha/2015-10/msg00403.html
the setting of _STRING_ARCH_unaligned currently controls the external
GLIBC ABI as well as selecting the use of unaligned accesses withing
GLIBC.
Since _STRING_ARCH_unaligned was recently changed for AArch64, this
would potentially break the ABI in GLIBC 2.23, so split the uses and add
_STRING_INLINE_unaligned to select the string ABI. This setting must be
fixed for each target, while _STRING_ARCH_unaligned may be changed from
release to release. _STRING_ARCH_unaligned is used unconditionally in
glibc. But <bits/string.h>, which defines _STRING_ARCH_unaligned, isn't
included with -Os. Since _STRING_ARCH_unaligned is internal to glibc and
may change between glibc releases, it should be made private to glibc.
_STRING_ARCH_unaligned should defined in the new string_private.h heade
file which is included unconditionally from internal <string.h> for glibc
build.
[BZ #19462]
* bits/string.h (_STRING_ARCH_unaligned): Renamed to ...
(_STRING_INLINE_unaligned): This.
* include/string.h: Include <string_private.h>.
* string/bits/string2.h: Replace _STRING_ARCH_unaligned with
_STRING_INLINE_unaligned.
* sysdeps/aarch64/bits/string.h (_STRING_ARCH_unaligned): Removed.
(_STRING_INLINE_unaligned): New.
* sysdeps/aarch64/string_private.h: New file.
* sysdeps/generic/string_private.h: Likewise.
* sysdeps/m68k/m680x0/m68020/string_private.h: Likewise.
* sysdeps/s390/string_private.h: Likewise.
* sysdeps/x86/string_private.h: Likewise.
* sysdeps/m68k/m680x0/m68020/bits/string.h
(_STRING_ARCH_unaligned): Renamed to ...
(_STRING_INLINE_unaligned): This.
* sysdeps/s390/bits/string.h (_STRING_ARCH_unaligned): Renamed
to ...
(_STRING_INLINE_unaligned): This.
* sysdeps/sparc/bits/string.h (_STRING_ARCH_unaligned): Renamed
to ...
(_STRING_INLINE_unaligned): This.
* sysdeps/x86/bits/string.h (_STRING_ARCH_unaligned): Renamed
to ...
(_STRING_INLINE_unaligned): This.
Building string/tst-endian.c with gcc 6 produces an build warning/error on s390 (big endian machine):
gcc tst-endian.c -c -std=gnu11 -fgnu89-inline -O2 or -O3 ...
tst-endian.c: In function ‘do_test’:
tst-endian.c:16:30: error: self-comparison always evaluates to false [-Werror=tautological-compare]
if (htobe16 (be16toh (i)) != i)
^~
...
See definitions of htobexx, bexxtoh in string/endian.h:
...
This patch silences these warnings with DIAG_* macros if build with gcc 6
and newer.
The same warnings occur on little endian machines with the
"htoleXX (leXXtoh (i)) != i" if-statements.
ChangeLog:
* string/tst-endian.c: Include <libc-internal.h>.
(do_test): Ignore tautological-compare warnings around
"htobeXX (beXXtoh (i)) != i" and
"htoleXX (leXXtoh (i)) != i" if-statements.
This automatically-generated patch converts 29 function definitions in
glibc (including one in an example in the manual) from old-style K&R
to prototype-style. Following my other recent such patches, this one
deals with the case of function definitions where one K&R parameter
declaration declares multiple parameters, as in:
void
foo (a, b)
int a, *b;
{
}
Tested for x86_64 and x86 (testsuite, and that installed stripped
shared libraries are unchanged by the patch).
* crypt/crypt.c (_ufc_doit_r): Convert to prototype-style function
definition.
(_ufc_doit_r): Likewise.
* crypt/crypt_util.c (_ufc_copymem): Likewise.
(_ufc_output_conversion_r): Likewise.
* inet/inet_mkadr.c (__inet_makeaddr): Likewise.
* inet/rcmd.c (rcmd_af): Likewise.
(rcmd): Likewise.
(ruserok_af): Likewise.
(ruserok): Likewise.
(ruserok2_sa): Likewise.
(ruserok_sa): Likewise.
(iruserok_af): Likewise.
(iruserok): Likewise.
(__ivaliduser): Likewise.
(__validuser2_sa): Likewise.
* inet/rexec.c (rexec_af): Likewise.
(rexec): Likewise.
* inet/ruserpass.c (ruserpass): Likewise.
* locale/programs/xmalloc.c (xcalloc): Likewise.
* manual/examples/timeval_subtract.c (timeval_subtract): Likewise.
* math/w_drem.c (__drem): Likewise.
* math/w_dremf.c (__dremf): Likewise.
* math/w_dreml.c (__dreml): Likewise.
* misc/daemon.c (daemon): Likewise.
* resolv/res_debug.c (p_fqnname): Likewise.
* stdlib/div.c (div): Likewise.
* string/memcmp.c (memcmp_bytes): Likewise.
* sunrpc/pmap_rmt.c (pmap_rmtcall): Likewise.
* sunrpc/svc_udp.c (svcudp_bufcreate): Likewise.
Fix the copyright year and remove contributed by in the
bug-strcoll2 test. In addition add the correct dependency
on $(gen-locales) to ensure all the test locales are generated.
The optimization introduced in commit
f13c2a8dff, causes regressions in
sorting for languages that have digraphs that change sort order, like
cs_CZ which sorts ch between h and i.
My analysis shows the fast-forwarding optimization in STRCOLL advances
through a digraph while possibly stopping in the middle which results
in a subsequent skipping of the digraph and incorrect sorting. The
optimization is incorrect as implemented and because of that I'm
removing it for 2.23, and I will also commit this fix for 2.22 where
it was originally introduced.
This patch reverts the optimization, introduces a new bug-strcoll2.c
regression test that tests both cs_CZ.UTF-8 and da_DK.ISO-8859-1 and
ensures they sort one digraph each correctly. The optimization can't be
applied without regressing this test.
Checked on x86_64, bug-strcoll2.c fails without this patch and passes
after. This will also get a fix on 2.22 which has the same bug.
This patch provides optimized versions of memccpy with the z13 vector
instructions.
ChangeLog:
* sysdeps/s390/multiarch/memccpy-c.c: New File.
* sysdeps/s390/multiarch/memccpy-vx.S: Likewise.
* sysdeps/s390/multiarch/memccpy.c: Likewise.
* sysdeps/s390/multiarch/Makefile
(sysdep_routines): Add memccpy functions.
* sysdeps/s390/multiarch/ifunc-impl-list-common.c
(__libc_ifunc_impl_list_common): Add ifunc test for memccpy.
* string/memccpy.c: Use MEMCCPY if defined.
This patch provides optimized versions of strcmp and wcscmp with the z13
vector instructions.
The architecture specific string.h had a typo, which leads to ommiting the
inline version in this file if __USE_STRING_INLINES is defined.
Tested this inline version by tweaking test-strcmp.c.
ChangeLog:
* sysdeps/s390/multiarch/strcmp-vx.S: New File.
* sysdeps/s390/multiarch/strcmp.c: Likewise.
* sysdeps/s390/multiarch/wcscmp-c.c: Likewise.
* sysdeps/s390/multiarch/wcscmp-vx.S: Likewise.
* sysdeps/s390/multiarch/wcscmp.c: Likewise.
* sysdeps/s390/s390-32/multiarch/strcmp.c: Likewise.
* sysdeps/s390/s390-64/multiarch/strcmp.c: Likewise.
* sysdeps/s390/multiarch/Makefile (sysdep_routines): Add strcmp and
wcscmp functions.
* sysdeps/s390/multiarch/ifunc-impl-list.c
(__libc_ifunc_impl_list): Add ifunc test for strcmp, wcscmp.
* string/strcmp.c (STRCMP): Define and use macro.
* benchtests/bench-wcscmp.c: New File.
* benchtests/Makefile (wcsmbs-bench): Add wcscmp.
* sysdeps/s390/bits/string.h: Fix typo: _HAVE_STRING_ARCH_strcmp
instead of _HAVE_STRING_ARCH_memchr.
This patch provides optimized versions of strlen and wcslen with the z13 vector
instructions.
The helper macro IFUNC_VX_IMPL is introduced and is used to register all
__<func>_c() and __<func>_vx() functions within __libc_ifunc_impl_list()
to the ifunc test framework.
ChangeLog:
* sysdeps/s390/multiarch/Makefile: New File.
* sysdeps/s390/multiarch/strlen-c.c: Likewise.
* sysdeps/s390/multiarch/strlen-vx.S: Likewise.
* sysdeps/s390/multiarch/strlen.c: Likewise.
* sysdeps/s390/multiarch/wcslen-c.c: Likewise.
* sysdeps/s390/multiarch/wcslen-vx.S: Likewise.
* sysdeps/s390/multiarch/wcslen.c: Likewise.
* string/strlen.c (STRLEN): Define and use macro.
* sysdeps/s390/multiarch/ifunc-impl-list.c
(IFUNC_VX_IMPL): New macro function.
(__libc_ifunc_impl_list): Add ifunc test for strlen, wcslen.
* benchtests/Makefile (wcsmbs-bench): New variable.
(string-bench-all): Added wcsmbs-bench.
* benchtests/bench-wcslen.c: New File.
I think the last clause of the conditional,
|| __n <= __bos (__dest)
may be backward. The code should call the runtime-checking function
if __n is not constant, or if __n is known to be LARGER than the size
of the destination.
This patches uses the default strcpy/stpcpy implementation for
POWER7/PPC64. This is faster in mostly inputs for benchtests
and for multiarch the implementation uses the POWER7 strlen and
memcpy.
* string/stpcpy.c (__stpcpy): Use STPCPY to redefine symbol name and
cleanup macro usage.
* string/strcpy.c (strcpt): Use STRCPY to redefine symbol name.
* sysdeps/powerpc/powerpc64/multiarch/stpcpy-power7.S: Remove file.
* sysdeps/powerpc/powerpc64/multiarch/stpcpy-ppc64.S: Likewise.
* sysdeps/powerpc/powerpc64/multiarch/strcpy-power7.S: Likewise.
* sysdeps/powerpc/powerpc64/multiarch/strcpy-ppc64.S: Likewise.
* sysdeps/powerpc/powerpc64/power7/stpcpy.S: Likewise.
* sysdeps/powerpc/powerpc64/power7/strcpy.S: Likewise.
* sysdeps/powerpc/powerpc64/power7/strcpy.c: Likewise.
* sysdeps/powerpc/powerpc64/stpcpy.S: Likewise.
* sysdeps/powerpc/powerpc64/strcpy.S: Likewise.
* sysdeps/powerpc/powerpc64/multiarch/stpcpy.c
[SHARED && IS_IN (libc)]: Include <string/strcpy.c>.
* sysdeps/powerpc/powerpc64/multiarch/stpcpy.c
[SHARED && IS_IN (libc)]: Include <string/stpcpy.c>.
* sysdeps/powerpc/powerpc64/multiarch/stpcpy-power7.c: New file.
* sysdeps/powerpc/powerpc64/multiarch/stpcpy-ppc64.c: Likewise.
* sysdeps/powerpc/powerpc64/multiarch/strcpy-power7.c: Likewise.
* sysdeps/powerpc/powerpc64/multiarch/strcpy-ppc64.c: Likewise.
* sysdeps/powerpc/powerpc64/power7/strcpy.c: Likewise.
These tests were skipped by the use-test-skeleton conversion done in
commit 29955b5d because they did not have an `int main (void)'
declaration. Instead their `main' functions were declared with arguments
(i.e. argc, argv) even though they didn't use them.
Remove these arguments and include the test skeleton in these tests.
on bench-strncpy is 1.9-2.1x faster on average. I tried several variations, and using a tailcall and
calling memset conditionally gave the best overall results.
Various code in glibc uses __strnlen instead of strnlen for namespace
reasons. However, __strnlen does not use libc_hidden_proto /
libc_hidden_def (as is normally done for any function defined and
called within the same library, whether or not exported from the
library and whatever namespace it is in), so the compiler does not
know that those calls are to a function within libc.
This patch uses libc_hidden_proto / libc_hidden_def with __strnlen.
On x86_64, it makes no difference to the installed stripped shared
libraries. On 32-bit x86, it causes __strnlen calls to go to the same
place as strnlen calls (the fallback strnlen implementation), rather
than through a PLT entry for the strnlen IFUNC; I'm not sure of the
logic behind when calls from within libc should use IFUNCs versus when
they should go direct to a particular function implementation, but
clearly it doesn't make sense for strnlen and __strnlen to be handled
differently in this regard.
Tested for x86_64 and x86 (testsuite, and comparison of installed
shared libraries as described above).
* string/strnlen.c [!STRNLEN] (__strnlen): Use libc_hidden_def.
* include/string.h (__strnlen): Use libc_hidden_proto.
* sysdeps/aarch64/strnlen.S (__strnlen): Use libc_hidden_def.
* sysdeps/i386/i686/multiarch/strnlen-c.c [SHARED]
(libc_hidden_def): Define __GI___strnlen as well as __GI_strnlen.
* sysdeps/powerpc/powerpc32/power4/multiarch/strnlen-power7.S
(libc_hidden_def): Undefine and redefine.
* sysdeps/powerpc/powerpc32/power4/multiarch/strnlen-ppc32.c
[SHARED] (libc_hidden_def): Define __GI___strnlen as well as
__GI_strnlen.
* sysdeps/powerpc/powerpc32/power7/strnlen.S (__strnlen): Use
libc_hidden_def.
* sysdeps/tile/tilegx/strnlen.c (__strnlen): Likewise.
pathconf (sysdeps/unix/sysv/linux/pathconf.c) uses basename. But
pathconf is in POSIX back to 1990 while basename is only reserved with
external linkage in those standards including XPG functions. This
patch fixes this namespace issue in the usual way, renaming basename
to __basename and making it into a weak alias.
Tested for x86_64 and x86 (testsuite, and that disassembly of
installed shared libraries is unchanged by the patch).
[BZ #18444]
* string/basename.c (basename): Rename to __basename and define as
weak alias of __basename. Use libc_hidden_weak.
* include/string.h (__basename): Declare. Use libc_hidden_proto.
* sysdeps/unix/sysv/linux/pathconf.c (distinguish_extX): Call
__basename instead of basename.
* conform/Makefile (test-xfail-POSIX2008/unistd.h/linknamespace):
Remove variable.
(test-xfail-XOPEN2K8/unistd.h/linknamespace): Likewise.
[BZ #18206]
* wcsmbs/wcsncmp.c (wcsncmp): Compare as wchar_t, not wint_t.
Use signed comparision instead of substraction to avoid
overflow bug.
* localedata/tests-mbwc/tst_wcsncmp.c (tst_wcsncmp):
Take the sign of ret.
* localedata/tests-mbwc/dat_wcsncmp.c (tst_wcsncmp_loc):
Do not expect precise return values. Only the sign matters.
* wcsmbs/Makefile (strop-tests): Add wcsncmp.
* wcsmbs/test-wcsncmp.c: New File.
* string/test-strncmp.c: Add wcsncmp support.
[Modified from the original email by Siddhesh Poyarekar]
This patch solves bug #16009 by implementing an additional path in
strxfrm that does not depend on caching the weight and rule indices.
In detail the following changed:
* The old main loop was factored out of strxfrm_l into the function
do_xfrm_cached to be able to alternativly use the non-caching version
do_xfrm.
* strxfrm_l allocates a a fixed size array on the stack. If this is not
sufficiant to store the weight and rule indices, the non-caching path is
taken. As the cache size is not dependent on the input there can be no
problems with integer overflows or stack allocations greater than
__MAX_ALLOCA_CUTOFF. Note that malloc-ing is not possible because the
definition of strxfrm does not allow an oom errorhandling.
* The uncached path determines the weight and rule index for every char
and for every pass again.
* Passing all the locale data array by array resulted in very long
parameter lists, so I introduced a structure that holds them.
* Checking for zero src string has been moved a bit upwards, it is
before the locale data initialization now.
* To verify that the non-caching path works correct I added a test run
to localedata/sort-test.sh & localedata/xfrm-test.c where all strings
are patched up with spaces so that they are too large for the caching path.
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.
TEST_IFUNC is only tested in two headers, bench-string.h and
test-string.h, after it gets defined by those headers, and it never
gets undefined.
Thus no defines of TEST_IFUNC are needed, and the *-ifunc.c tests that
just define TEST_IFUNC and include other tests are also redundant, as
is the code to remove $(tests-ifunc) and $(xtests-ifunc) conditionally
from tests and xtests. This patch removes the useless defines and
tests of TEST_IFUNC and the associated useless tests and makefile
code. It thereby fixes a series of warnings
"../string/test-string.h:21:0: warning: "TEST_IFUNC" redefined" where
test-string.h defines TEST_IFUNC to empty, other files define it to 1
and this produces warnings.
Tested for x86_64.
* debug/test-stpcpy_chk-ifunc.c: Remove file.
* debug/test-strcpy_chk-ifunc.c: Likewise.
* wcsmbs/test-wcschr-ifunc.c: Likewise.
* wcsmbs/test-wcscmp-ifunc.c: Likewise.
* wcsmbs/test-wcscpy-ifunc.c: Likewise.
* wcsmbs/test-wcslen-ifunc.c: Likewise.
* wcsmbs/test-wcsrchr-ifunc.c: Likewise.
* wcsmbs/test-wmemcmp-ifunc.c: Likewise.
* Rules [$(multi-arch) = no] (tests): Do not filter out
$(tests-ifunc).
[$(multi-arch) = no] (xtests): Do not filter out $(xtests-ifunc).
* debug/Makefile (tests-ifunc): Remove variable.
(tests): Do not add $(tests-ifunc).
* wcsmbs/Makefile (tests-ifunc): Remove variable.
(tests): Do not add $(tests-ifunc).
* benchtests/bench-string.h (TEST_IFUNC): Remove macro.
[TEST_IFUNC]: Remove conditionals.
* string/test-string.h (TEST_IFUNC): Remove macro.
[TEST_IFUNC]: Remove conditionals.
string/test-strchr.c is used for both wide and narrow string testing,
but produces a series of warnings for wide string testing because of
hardcoded use of narrow characters in the function check1. This patch
fixes that function to use macros abstracting away the wide / narrow
string choice, adding a new such macro to handle the string and
character constants.
Tested for x86_64.
* string/test-strchr.c [!WIDE] (L): New macro.
[WIDE] (L): Likewise.
(check1): Use CHAR instead of char. Use L on string and character
constants.
This patch fixes the build of C mempcpy and stpcpy by disabling the
redirection to __mempcpy and __stpcpy asm names if
NO_MEMPCPY_STPCPY_REDIRECT is defined, and defining that macro in the
relevant source files.
Tested for powerpc32 that the build is fixed.
* include/string.h [NO_MEMPCPY_STPCPY_REDIRECT] (mempcpy): Do not
redeclare with asm name.
[NO_MEMPCPY_STPCPY_REDIRECT] (stpcpy): Likewise.
* string/mempcpy.c (NO_MEMPCPY_STPCPY_REDIRECT): Define before
including <string.h>.
* string/stpcpy.c (NO_MEMPCPY_STPCPY_REDIRECT): Likewise.
* sysdeps/powerpc/powerpc32/power4/multiarch/mempcpy.c
[!NOT_IN_libc] (NO_MEMPCPY_STPCPY_REDIRECT): Likewise.
* sysdeps/powerpc/powerpc64/multiarch/mempcpy.c
[!NOT_IN_libc] (NO_MEMPCPY_STPCPY_REDIRECT): Likewise.
* sysdeps/powerpc/powerpc64/multiarch/stpcpy.c
[SHARED && !NOT_IN_libc] (NO_MEMPCPY_STPCPY_REDIRECT): Likewise.
Locale code, brought in by ISO C functions, calls memmem, which is not
an ISO C function. This isn't an ISO C conformance bug, because all
mem* names are reserved, but glibc practice is not to rely on that
reservation (thus, memmem is only declared in string.h if __USE_GNU
even though ISO C would allow it to be declared unconditionally, for
example). This patch changes that code to use __memmem.
Note: there are uses of memmem elsewhere in glibc that I didn't
change, although it may turn out some of those also need to use
__memmem.
Tested for x86_64 (testsuite, and that disassembly of installed shared
libraries is unchanged by this patch).
[BZ #17585]
* string/memmem.c [!_LIBC] (__memmem): Define to memmem.
(memmem): Rename to __memmem and define as weak alias of
__memmem. Use libc_hidden_weak.
(__memmem): Use libc_hidden_def.
* include/string.h (__memmem): Declare. Use libc_hidden_proto.
* locale/findlocale.c (valid_locale_name): Use __memmem instead of
memmem.
Modifies the test examination in test-skeleton.c so that a test can be
successful if it is interrupted or it returns uninterrupted with the
expected status. For this both EXPECTED_SIGNAL and EXPECTED_STATUS
have to be set, as is done in tst-strcoll-overflow.c.
this
will improve performance even on targets which don't have an optimized strlen. It is about twice
as
fast as the original strncat in bench-strncat.
implementation, so this improves performance even on targets which don't have an optimized
strlen and strcpy - it is 25% faster in bench-strcat. On targets which don't provide an
optimized strcat but which do have an optimized strlen and strcpy, performance gain is > 2x.
this is a path that should solve bug 15884. It complains about the performance
of strcoll(). It was found out that the runtime of strcoll() is actually bound
to strlen which is needed for calculating the size of a cache that was
installed to improve the comparison performance.
The idea for this patch was that the cache is only useful in rare cases
(strings of same length and same first-level-chars) and that it would be
better to avoid memory allocation at all. To prove this I wrote a performance
test bench-strcoll.c with test data in benchtests-strcoll.tar.gz. Also
modifications in benchtests/Makefile and localedata/Makefile are necessary to
make it work.
After removing the cache the strcoll method showed the predicted behavior
(getting slightly faster) in all but the test case for hindi word sorting.
This was due the hindi text having much more equal words than the other ones.
For equal strings the performance was worse since all comparison levels were
run through and from the second level on the cache improved the comparison
performance of the original version.
Therefore I added a bytewise test via strcmp iff the first level comparison
found that both strings did match because in this case it is very likely that
equal strings are compared. This solved the problem with the hindi test case
and improved the performance of the others.
Performance comparison:
glibc files -33.77%
vi_VN.UTF-8 -34.12%
en_US.UTF-8 -42.42%
ar_SA.UTF-8 -27.49%
zh_CN.UTF-8 +07.90%
cs_CZ.UTF-8 -29.67%
en_GB.UTF-8 -28.50%
da_DK.UTF-8 -36.57%
pl_PL.UTF-8 -39.31%
fr_FR.UTF-8 -28.57%
pt_PT.UTF-8 -22.82%
el_GR.UTF-8 -26.77%
ru_RU.UTF-8 -35.81%
iw_IL.UTF-8 -35.34%
es_ES.UTF-8 -34.46%
hi_IN.UTF-8 -00.38%
sv_SE.UTF-8 -36.99%
hu_HU.UTF-8 -16.35%
tr_TR.UTF-8 -27.80%
is_IS.UTF-8 -33.24%
it_IT.UTF-8 -24.39%
sr_RS.UTF-8 -37.55%
ja_JP.UTF-8 +02.84%
This patch adds an optimized memmove optimization for POWER7/powerpc64.
Basically the idea is to use the memcpy for POWER7 on non-overlapped
memory regions and a optimized backward memcpy for memory regions
that overlap (similar to the idea of string/memmove.c).
The backward memcpy algorithm used is similar the one use for memcpy for
POWER7, with adjustments done for alignment. The difference is memory
is always aligned to 16 bytes before using VSX/altivec instructions.
Merge most of the gnulib implementation of memchr. The changes that
remain are:
- copyright header
- bp-sym.h removed
- reg_char removed
- allow MEMCHR to be redefined
- non-conforming whitespace changes
The merged code fixes a number of -Wundef warnings and also introduces
an optimized algorithm. I haven't detected any performance difference
in the new code which I believe is down to the quite specific
circumstances required to hit it. However the new code is approximately
half the size of the old code on AArch64 (which uses generic memchr).
ChangeLog:
2014-07-04 Will Newton <will.newton@linaro.org>
* string/memchr.c: Merge from gnulib.
[_LIBC]: Remove conditionals.
(__ptr_t): Remove define.
(LONG_MAX_32_BITS): Likewise.
(LONG_MAX): Likewise.
(MEMCHR): Use ANSI prototype and optimize algorithm.
The PAGE_COPY_THRESHOLD macro is meant to be overridden by
architecture-specific pagecopy.h, but it is currently done only by
mach; all other architectures use the default. Check to see if the
macro is defined in addition to whether it is set to a non-zero value.
Joseph Myers
Adhemerval Zanella
Nick Alcock
Wilco Dijkstra
Florian Weimer
Zack Weinberg
Carlos O'Donell
Adhemerval Zanella
David S. Miller
H.J. Lu
H.J. Lu
Stefan Liebler
Carlos O'Donell
Martin Sebor
Paul Eggert
Arjun Shankar
Leonhard Holz
Andreas Schwab
Ondřej Bílka
Richard Earnshaw
Torvald Riegel
Siddhesh Poyarekar
Roland McGrath
Adhemerval Zanella
Will Newton