Add the missing fallback file for elide.h to fix non x86 builds.
Sorry about that. This is just a noop macro file that makes
all elision code to be optimized out.
With the recent tuning the C version of rwlocks is basically the same
performance as the x86 assembler version for uncontended locks (with a
a few cycles near the run-to-run variability). For others it should not
matter anyways.
So remove the assembler code and use the C version like other
architectures.
This patch relies on the C version of the rwlocks posted earlier.
With C rwlocks it is very straight forward to do adaptive elision
using TSX. It is based on the infrastructure added earlier
for mutexes, but uses its own elision macros. The macros
are fairly general purpose and could be used for other
elision purposes too.
This version is much cleaner than the earlier assembler based
version, and in particular implements adaptation which makes
it safer.
I changed the behavior slightly to not require any changes
in the test suite and fully conform to all expected
behaviors (generally at the cost of not eliding in
various situations). In particular this means the timedlock
variants are not elided. Nested trylock aborts.
The implementation of __get_nprocs uses a stactic variable to cache
the value of the current number of processors. The caching breaks when
'time (NULL) == 0':
$ cat nproc.c
#include <stdio.h>
#include <time.h>
#include <sys/time.h>
int main(int argc, char *argv[])
{
time_t t;
struct timeval tv = {0, 0};
printf("settimeofday({0, 0}, NULL) = %d\n", settimeofday(&tv, NULL));
t = time(NULL);
printf("Time: %d, CPUs: %d\n", (unsigned int)t, get_nprocs());
return 0;
}
$ gcc -O3 nproc.c
$ ./a.out
settimeofday({0, 0}, NULL) = -1
Time: 1401311578, CPUs: 4
$ sudo ./a.out
settimeofday({0, 0}, NULL) = 0
Time: 0, CPUs: 0
The problem is with the condition used to check whether a cached
value should be returned or not:
static int cached_result;
static time_t timestamp;
time_t now = time (NULL);
time_t prev = timestamp;
atomic_read_barrier ();
if (now == prev)
return cached_result;
This patch fixes the problem by ensuring that 'cached_result' has
been set at least once before returning it.
Optimization is achieved on 8 byte aligned strings with double word
comparison using cmpb instruction. On unaligned strings loop unrolling
is applied for Power7 gain.
As with other issues of this kind, bug 17042 is log2 (1) wrongly
returning -0 instead of +0 in round-downward mode because of
implementations effectively in terms of log1p (x - 1). This patch
fixes the issue in the same way used for log and log10.
Tested x86_64 and x86 and ulps updated accordingly. Also tested for
mips64 to confirm a fix was needed for ldbl-128 and to validate that
fix (also applied to ldbl-128ibm since that version of log2l is
essentially the same as the ldbl-128 one).
[BZ #17042]
* sysdeps/i386/fpu/e_log2.S (__ieee754_log2): Take absolete value
when x - 1 is zero.
* sysdeps/i386/fpu/e_log2f.S (__ieee754_log2f): Likewise.
* sysdeps/i386/fpu/e_log2l.S (__ieee754_log2l): Likewise.
* sysdeps/ieee754/ldbl-128/e_log2l.c (__ieee754_log2l): Return
0.0L for an argument of 1.0L.
* sysdeps/ieee754/ldbl-128ibm/e_log2l.c (__ieee754_log2l):
Likewise.
* sysdeps/x86_64/fpu/e_log2l.S (__ieee754_log2l): Take absolute
value when x - 1 is zero.
* math/libm-test.inc (log2_test): Use ALL_RM_TEST.
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
The hppa port has no need of a custom lowlevellock.c, it should
use the generic version which is updated and correct. This
similarly fixes bug 15119 for hppa.
Various glibc build / install / test code has C locale settings that
are redundant with LC_ALL=C.
LC_ALL takes precedence over LANG, so anywhere that sets LC_ALL=C
(explicitly, or through it being in the default environment for
running tests) does not need to set LANG=C. LC_ALL=C also takes
precedence over LANGUAGE, since
2001-01-02 Ulrich Drepper <drepper@redhat.com>
* intl/dcigettext.c (guess_category_value): Rewrite so that LANGUAGE
value is ignored if the selected locale is the C locale.
* intl/tst-gettext.c: Set locale for above change.
* intl/tst-translit.c: Likewise.
and so settings of LANGUAGE=C are also redundant when LC_ALL=C is
set. One test also had LC_ALL=C in its -ENV setting, although it's
part of the default environment used for tests.
This patch removes the redundant settings. It removes a suggestion in
install.texi of setting LANGUAGE=C LC_ALL=C for "make install"; the
Makefile.in target "install" already sets LC_ALL_C so there's no need
for the user to set it (and nor should there be any need for the user
to set it).
If some build machine tool used by "make install" uses a version of
libintl predating that 2001 change, and the user has LANGUAGE set, the
removal of LANGUAGE=C from the Makefile.in "install" rule could in
principle affect the user's installation. However, I don't think we
need to be concerned about pre-2001 build tools.
Tested x86_64.
* Makefile (install): Don't set LANGUAGE.
* Makefile.in (install): Likewise.
* assert/Makefile (test-assert-ENV): Remove variable.
(test-assert-perr-ENV): Likewise.
* elf/Makefile (neededtest4-ENV): Likewise.
* iconvdata/Makefile ($(inst_gconvdir)/gconv-modules)
[$(cross-compiling) = no]: Don't set LANGUAGE.
* io/ftwtest-sh (LANG): Remove variable.
* libio/Makefile (tst-widetext-ENV): Likewise.
* manual/install.texi (Running make install): Don't refer to
environment settings for make install.
* INSTALL: Regenerated.
* nptl/tst-tls6.sh: Don't set LANG.
* posix/globtest.sh (LANG): Remove variable.
* string/Makefile (tester-ENV): Likewise.
(inl-tester-ENV): Likewise.
(noinl-tester-ENV): Likewise.
* sysdeps/s390/s390-64/Makefile ($(inst_gconvdir)/gconv-modules)
[$(cross-compiling) = no]: Don't set LANGUAGE.
* timezone/Makefile (build-testdata): Use $(built-program-cmd)
without explicit environment settings.
localedata/ChangeLog:
* tst-fmon.sh: Don't set LANGUAGE.
* tst-locale.sh: Likewise.
This patch fixes the optimized ppc64/power7 strncat strlen call for
static build without ifunc enabled. The strlen symbol to call in such
situation is just strlen, instead of __GI_strlen (since the __GI_
alias is just created for shared objects).
In several cases we've had asm routines rely on syscalls not clobbering
call-clobbered registers, and that's now deemed ABI. So take advantage
of this in the INLINE_SYSCALL path as well.
Shrinks libc.so by about 1k.
The current code for handling concurrent resolution says that the
ABI for _dl_tlsdesc_resolve_hold is the same as that of
_dl_tlsdesc_lazy_resolver. However _dl_tlsdesc_resolve_hold is
called from the trampoline directly rather than the lazy resolver
stub so, for example, r2 has not been pushed so does not needed
to be restored.
This fixes an intermittent failure in nptl/tst-tls3 when building
glibc for arm-linux-gnueabihf with -mtls-dialect=gnu2.
ChangeLog:
2014-05-27 Will Newton <will.newton@linaro.org>
[BZ #16990]
* sysdeps/arm/dl-tlsdesc.S (_dl_tlsdesc_resolve_hold): Save
and restore r2 rather than just restoring.
This fixes a variety of testsuite failures for me:
tststatic.out Error 1
tststatic2.out Error 1
tst-tls9-static.out Error 1
tst-audit8.out Error 127
tst-audit9.out Error 127
tst-audit1.out Error 127
and also has the added benefit of making LD_AUDIT/sotruss work on
AArch64.
Otherwise, we bail out early in _dl_try_allocate_static_tls as the
alignment requirement of the PT_TLS section in libc is 16.
This macro was removed by
2005-11-16 Daniel Jacobowitz <dan@codesourcery.com>
but not applied to the (still separate) eabi port so necro'd
when the eabi port superceded the old abi. It was thence
copied into the new AArch64 port.
As with various other issues of this kind, bug 16977 is log10 (1)
wrongly returning -0 rather than +0 in round-downward mode because of
an implementation effectively in terms of log1p (x - 1). This patch
fixes the issue in the same way used for log.
Tested x86_64 and x86 and ulps updated accordingly. Also tested for
mips64 to confirm a fix was needed for ldbl-128 and to validate that
fix (also applied to ldbl-128ibm since that version of logl is
essentially the same as the ldbl-128 one).
[BZ #16977]
* sysdeps/i386/fpu/e_log10.S (__ieee754_log10): Take absolute
value when x - 1 is zero.
* sysdeps/i386/fpu/e_log10f.S (__ieee754_log10f): Likewise.
* sysdeps/i386/fpu/e_log10l.S (__ieee754_log10l): Likewise.
* sysdeps/ieee754/ldbl-128/e_log10l.c (__ieee754_log10l): Return
0.0L for an argument of 1.0L.
* sysdeps/ieee754/ldbl-128ibm/e_log10l.c (__ieee754_log10l):
Likewise.
* sysdeps/x86_64/fpu/e_log10l.S (__ieee754_log10l): Take absolute
value when x - 1 is zero.
* math/libm-test.inc (log10_test): Use ALL_RM_TEST.
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
This patch fixes a similar issue to
736c304a1a, where for PPC32 if the symbol
is defined as hidden (memchr) then compiler will create a local branc
(symbol@local) and the linker will not create a required PLT call to
make the ifunc work. It changes the default hidden symbol (__GI_memchr)
to default memchr symbol for powerpc32 (__memchr_ppc32).
As previously noted
<https://sourceware.org/ml/libc-alpha/2013-05/msg00696.html>,
$(elf-objpfx) and $(elfobjdir) are redundant and should be
consolidated. This patch consolidates on $(elf-objpfx) (for
consistency with $(csu-objpfx)), also changing direct uses of
$(common-objpfx)elf/ to use $(elf-objpfx).
Tested x86_64, including that installed shared libraries are unchanged
by the patch.
* Makeconfig [$(build-hardcoded-path-in-tests) = yes]
(rtld-tests-LDFLAGS): Use $(elf-objpfx) instead of
$(common-objpfx)elf/.
(link-libc-before-gnulib): Likewise.
(elfobjdir): Remove variable.
* Makefile (install): Use $(elf-objpfx) instead of
$(common-objpfx)elf/.
* Makerules (link-libc-args): Use $(elf-objpfx) instead of
$(elfobjdir)/.
(link-libc-deps): Likewise.
($(common-objpfx)libc.so): Likewise.
($(common-objpfx)linkobj/libc.so): Likewise.
[$(cross-compiling) = no] (symbolic-link-prog): Use $(elf-objpfx)
instead of $(common-objpfx)elf/.
(symbolic-link-list): Likewise.
* iconvdata/Makefile ($(inst_gconvdir)/gconv-modules)
[$(cross-compiling) = no]: Likewise.
* sysdeps/arm/Makefile (gnulib-arch): Use $(elf-objpfx) instead of
$(elfobjdir)/.
(static-gnulib-arch): Likewise.
* sysdeps/s390/s390-64/Makefile ($(inst_gconvdir)/gconv-modules)
[$(cross-compiling) = no]: Use $(elf-objpfx) instead of
$(common-objpfx)elf/.
localedata/ChangeLog:
* Makefile (LOCALEDEF): Use $(elf-objpfx) instead of
$(common-objpfx)elf/.
This also highlights that we'd been loading 64-bits instead of
the proper 32-bits. Caught by the linker as a relocation error,
since the variable happened to be unaligned for 64-bits.
sysdeps/unix/sysv/linux/arm/unwind-resume.c and
sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c have static
variables that are written in C code but only read from toplevel asms.
Current GCC trunk now optimizes away such apparently write-only static
variables, so causing a build failure. This patch marks those
variables with __attribute_used__ to avoid that optimization.
Tested that this fixes the build for ARM.
* sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c
(libgcc_s_resume): Use __attribute_used__.
* sysdeps/unix/sysv/linux/arm/unwind-resume.c (libgcc_s_resume):
Likewise.
This patch fixes the __copysignf optimized macro meant to internal libm
usage when used with constant value. Without the explicit cast to
float, if it is used with const double value (for instance, on
s_casinhf.c) double constants will be used and it may lead to precision
issues in some algorithms.
It fixes the following failures on PPC64/POWER7:
Failure: Test: Real part of: cacos_downward (inf + 0 i)
Result:
is: 1.19209289550781250000e-07 0x1.00000000000000000000p-23
should be: 0.00000000000000000000e+00 0x0.00000000000000000000p+0
Failure: Test: Real part of: cacos_downward (inf - 0 i)
Result:
is: 1.19209289550781250000e-07 0x1.00000000000000000000p-23
should be: 0.00000000000000000000e+00 0x0.00000000000000000000p+0
Failure: Test: Real part of: cacos_downward (inf + 0.5 i)
Result:
is: 1.19209289550781250000e-07 0x1.00000000000000000000p-23
should be: 0.00000000000000000000e+00 0x0.00000000000000000000p+0
Failure: Test: Real part of: cacos_downward (inf - 0.5 i)
Result:
is: 1.19209289550781250000e-07 0x1.00000000000000000000p-23
should be: 0.00000000000000000000e+00 0x0.00000000000000000000p+0
Failure: Test: Real part of: cacos_towardzero (inf + 0 i)
Result:
is: 1.19209289550781250000e-07 0x1.00000000000000000000p-23
should be: 0.00000000000000000000e+00 0x0.00000000000000000000p+0
Failure: Test: Real part of: cacos_towardzero (inf - 0 i)
Result:
is: 1.19209289550781250000e-07 0x1.00000000000000000000p-23
should be: 0.00000000000000000000e+00 0x0.00000000000000000000p+0
Failure: Test: Real part of: cacos_towardzero (inf + 0.5 i)
Result:
is: 1.19209289550781250000e-07 0x1.00000000000000000000p-23
should be: 0.00000000000000000000e+00 0x0.00000000000000000000p+0
Failure: Test: Real part of: cacos_towardzero (inf - 0.5 i)
Result:
is: 1.19209289550781250000e-07 0x1.00000000000000000000p-23
should be: 0.00000000000000000000e+00 0x0.00000000000000000000p+0
Using the default header instead. This matches the kernel, which also
uses the generic header. Fixes the sys/wait.h conform issue, where
si_band had the wrong type.
The current code for nocancel syscalls does not do a comparison of
the system call return value. This leads to code being generated
where the b.cs follows the svc instruction directly without setting
the flags on which the branch depends.
ChangeLog:
2014-05-20 Will Newton <will.newton@linaro.org>
* sysdeps/unix/sysv/linux/aarch64/nptl/sysdep-cancel.h (PSEUDO):
Test the return value of the system call in the nocancel case.
This patch fixes an issue observed by the Xen project, where including
signal.h exposes various PSR_MODE #defines. This is due to the usage
in sys/user.h and sys/procfs.h of the struct user_pt_regs and
user_fpsimd_state included via asm/ptrace.h. The namespace pollution
this inclusion introduce is already partially fixed with some #undef
of the PTRACE_* symbols, but other symbols like the PSR_MODE ones are
still present, and undefining them is not safe since a user can
include ptrace.h before user.h.
My proposition is to define the 2 structures we need in user.h and get
rid of the asm/ptrace.h inclusion.
Build and make check are clean on AArch64.
2014-05-20 Will Newton <will.newton@linaro.org>
Yvan Roux <yvan.roux@linaro.org>
* sysdeps/unix/sysv/linux/aarch64/sys/user.h: Remove unused
#include of asm/ptrace.h.
(PTRACE_GET_THREAD_AREA): Remove #undef.
(PTRACE_GETHBPREGS): Likewise.
(PTRACE_SETHBPREGS): Likewise.
(struct user_regs_struct): New structure.
(struct user_fpsimd_struct): New structure.
* sysdeps/unix/sysv/linux/aarch64/sys/procfs.h: Remove unused
#include of asm/ptrace.h and second #include of sys/user.h.
(PTRACE_GET_THREAD_AREA): Remove #undef.
(PTRACE_GETHBPREGS): Likewise.
(PTRACE_SETHBPREGS): Likewise.
(ELF_NGREG): Use new struct user_regs_struct.
(elf_fpregset_t): Use new struct user_fpsimd_struct.
Commit 7d92b78723 [Fix ARM NAN fraction
bits.] removed all the bits set from NANFRAC macros and, when propagated
to libgcc, regressed gcc.dg/torture/builtin-math-7.c on soft-fp arm-eabi
targets, currently ARMv6-M (`-march=armv6-m -mthumb') only. This is
because when used to construct a NaN in the semi-raw mode, they now
build an infinity instead. Consequently operations such as (Inf - Inf)
now produce Inf rather than NaN. The change worked for the original
test case, posted with PR libgcc/60166, because division is made in the
canonical mode, where the quiet bit is set separately, from the fp
class.
This change brings the quiet bit back to these macros, making semi-raw
mode calculations produce the expected results again.
This patch guard the BSD definition for terminal modes in PowerPC
specific header fixing the following conformance failures:
FAIL: conform/POSIX/termios.h/conform
FAIL: conform/POSIX2008/termios.h/conform
FAIL: conform/UNIX98/termios.h/conform
prlimit and prlimit64 have been added in the main <bits/resource.h>, but
not in the SPARC specific version. Fix that.
Note: this is Debian bug#703559, reported by Emilio Pozuelo Monfort
<pochu@debian.org>
If the fd refers to a terminal device, but not a pty master, the
TIOCGPTN ioctl returns with ENOTTY. This error is not caught, and the
possibly undefined buffer passed to ptsname_r is sent directly to the
stat64 syscall.
Fix this by using a fallback to the old method only if the TIOCGPTN
ioctl fails with EINVAL. This also fix the return value in that specific
case (it return ENOENT without this patch).
Also add tests to the ptsname_r function (and ptsname at the same time).
Note: this is Debian bug#741482, reported by Jakub Wilk <jwilk@debian.org>
getaddrinfo correctly returns EAI_AGAIN for AF_INET and AF_INET6
queries. For AF_UNSPEC however, an older change
(a682a1bf55) broke the check and due to
that the returned error was EAI_NONAME.
This patch fixes the check so that a non-authoritative not-found is
returned as EAI_AGAIN to the user instead of EAI_NONAME.
Bug 16564 is spurious overflow of log1pl (LDBL_MAX) in FE_UPWARD mode,
resulting from log1pl adding 1 to its argument (for arguments not
close to 0), which overflows in that mode. This patch fixes this by
avoiding adding 1 to large arguments (precisely what counts as large
depends on the floating-point format).
Tested x86_64 and x86, and spot-checked log1pl tests on mips64 and
powerpc64.
[BZ #16564]
* sysdeps/i386/fpu/s_log1pl.S (__log1pl): Do not add 1 to positive
arguments with exponent 65 or above.
* sysdeps/ieee754/ldbl-128/s_log1pl.c (__log1pl): Do not add 1 to
arguments 0x1p113L or above.
* sysdeps/ieee754/ldbl-128ibm/s_log1pl.c (__log1pl): Do not add 1
to arguments 0x1p107L or above.
* sysdeps/x86_64/fpu/s_log1pl.S (__log1pl): Do not add 1 to
positive arguments with exponent 65 or above.
* math/auto-libm-test-in: Add more tests of log1p.
* math/auto-libm-test-out: Regenerated.
According to C99/C11 Annex G, cacos applied to a value with real part
+Inf and finite imaginary part should produce a result with real part
+0. glibc wrongly produces a result with real part -0 in FE_DOWNWARD
mode. This patch fixes this by checking for zero results in the
relevant case of non-finite arguments (where there should never be a
result with -0 real part), and converts the tests of cacos to
ALL_RM_TEST.
Tested x86_64 and x86 and ulps updated accordingly.
[BZ #16928]
* math/s_cacos.c (__cacos): Ensure zero real part of result from
non-finite arguments is +0.
* math/s_cacosf.c (__cacosf): Likewise.
* math/s_cacosl.c (__cacosl): Likewise.
* math/libm-test.inc (cacos_test): Use ALL_RM_TEST.
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
According to C99 and C11 Annex F, acosh (1) should be +0 in all
rounding modes. However, some implementations in glibc wrongly return
-0 in round-downward mode (which is what you get if you end up
computing log1p (-0), via 1 - 1 being -0 in round-downward mode).
This patch fixes the problem implementations, by correcting the test
for an exact 1 value in the ldbl-96 implementation to allow for the
explicit high bit of the mantissa, and by inserting fabs instructions
in the i386 implementations; tests of acosh are duly converted to
ALL_RM_TEST. I believe all the other sysdeps/ieee754 implementations
are already OK (I haven't checked the ia64 versions, but if buggy then
that will be obvious from the results of test runs after this patch is
in).
Tested x86_64 and x86 and ulps updated accordingly.
[BZ #16927]
* sysdeps/i386/fpu/e_acosh.S (__ieee754_acosh): Use fabs on x-1
value.
* sysdeps/i386/fpu/e_acoshf.S (__ieee754_acoshf): Likewise.
* sysdeps/i386/fpu/e_acoshl.S (__ieee754_acoshl): Likewise.
* sysdeps/ieee754/ldbl-96/e_acoshl.c (__ieee754_acoshl): Correct
for explicit high bit of mantissa when testing for argument equal
to 1.
* math/libm-test.inc (acosh_test): Use ALL_RM_TEST.
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
Bug 16516 reports spurious underflows from erf (for all floating-point
types), when the result is close to underflowing but does not actually
underflow.
erf (x) is about (2/sqrt(pi))*x for x close to 0, so there are
subnormal arguments for which it does not underflow. The various
implementations do (x + efx*x) (for efx = 2/sqrt(pi) - 1), for greater
accuracy than if just using a single multiplication by an
approximation to 2/sqrt(pi) (effectively, this way there are a few
more bits in the approximation to 2/sqrt(pi)). This can introduce
underflows when efx*x underflows even though the final result does
not, so a scaled calculation with 8*efx is done in these cases - but 8
is not a big enough scale factor to avoid all such underflows. 16 is
(any underflows with a scale factor of 16 would only occur when the
final result underflows), so this patch changes the code to use that
factor. Rather than recomputing all the values of the efx8 variable,
it is removed, leaving it to the compiler's constant folding to
compute 16*efx. As such scaling can also lose underflows when the
final scaling down happens to be exact, appropriate checks are added
to ensure underflow exceptions occur when required in such cases.
Tested x86_64 and x86; no ulps updates needed. Also spot-checked for
powerpc32 and mips64 to verify the changes to the ldbl-128ibm and
ldbl-128 implementations.
[BZ #16516]
* sysdeps/ieee754/dbl-64/s_erf.c (efx8): Remove variable.
(__erf): Scale by 16 instead of 8 in potentially underflowing
case. Ensure exception if result actually underflows.
* sysdeps/ieee754/flt-32/s_erff.c (efx8): Remove variable.
(__erff): Scale by 16 instead of 8 in potentially underflowing
case. Ensure exception if result actually underflows.
* sysdeps/ieee754/ldbl-128/s_erfl.c: Include <float.h>.
(efx8): Remove variable.
(__erfl): Scale by 16 instead of 8 in potentially underflowing
case. Ensure exception if result actually underflows.
* sysdeps/ieee754/ldbl-128ibm/s_erfl.c: Include <float.h>.
(efx8): Remove variable.
(__erfl): Scale by 16 instead of 8 in potentially underflowing
case. Ensure exception if result actually underflows.
* sysdeps/ieee754/ldbl-96/s_erfl.c: Include <float.h>.
(efx8): Remove variable.
(__erfl): Scale by 16 instead of 8 in potentially underflowing
case. Ensure exception if result actually underflows.
* math/auto-libm-test-in: Add more tests of erf.
* math/auto-libm-test-out: Regenerated.
This patch reduces duplication between different architectures'
kernel-features.h files by making the architecture-independent file
define various macros unconditionally (instead of only for a
particular list of architectures), with the architecture-specific
files then undefining the macros if necessary.
Specifically, __ASSUME_O_CLOEXEC (O_CLOEXEC flag to open) and
__ASSUME_SOCK_CLOEXEC (SOCK_NONBLOCK and SOCK_CLOEXEC flags to socket)
are supported on all architectures as of 2.6.32 or the minimum kernel
version for the architecture if later. For __ASSUME_IN_NONBLOCK,
__ASSUME_PIPE2, __ASSUME_EVENTFD2, __ASSUME_SIGNALFD4 and
__ASSUME_DUP3, the relevant syscalls were added for alpha in 2.6.33
but otherwise the features are available as of 2.6.32. For
__ASSUME_UTIMES, support is everywhere in 2.6.32 except for
asm-generic architectures and hppa.
Although those were the main cases of duplication among
kernel-features.h files, some other cases of unnecessary definitions
were also cleaned up: the hppa file defined various macros that were
either no longer used at all, or defined by the main file by default
anyway, the ia64 file had duplicative definitions of __ASSUME_PSELECT
and __ASSUME_PPOLL, while mips had such a definition of
__ASSUME_IPC64.
Really, rather than being defined in the main file then undefined for
asm-generic architectures, __ASSUME_UTIMES should become an
hppa-specific macro. Given that __ASSUME_ATFCTS and
__ASSUME_UTIMENSAT are now always true, the only live __ASSUME_UTIMES
conditional is in sysdeps/unix/sysv/linux/utimes.c, which is not used
for asm-generic architectures. I think the desired state would be an
hppa-specific file (that includes sysdeps/unix/sysv/linux/utimes.c if
__ASSUME_UTIMES, and otherwise has fallback code), with the fallback
code being removed from the main utimes.c. But I think that's most
reasonably a separate cleanup once __ASSUME_ATFCTS and
__ASSUME_UTIMESAT have both had conditional code cleaned up.
Given this patch, I think it's straightforward to move non-ex-ports
architectures to having their own kernel-features.h files, like
ex-ports architectures, rather than conditionals in the main file
(i.e., such a move won't require the architecture-specific file to
contain anything that isn't genuinely architecture-specific), and
would encourage architecture maintainers to do so.
Tested x86_64 that the installed shared libraries are unchanged by
this patch. Note that on some architectures this *will* cause
__ASSUME_* macros to be defined in cases where they weren't previously
but should have been (but this is just optimization, not a fix to a
user-visible bug, so doesn't need a bug report in Bugzilla).
* sysdeps/unix/sysv/linux/kernel-features.h (__ASSUME_UTIMES):
Define unconditionally.
(__ASSUME_O_CLOEXEC): Likewise.
(__ASSUME_SOCK_CLOEXEC): Likewise.
(__ASSUME_IN_NONBLOCK): Likewise.
(__ASSUME_PIPE2): Likewise.
(__ASSUME_EVENTFD2): Likewise.
(__ASSUME_SIGNALFD4): Likewise.
(__ASSUME_DUP3): Likewise.
* sysdeps/unix/sysv/linux/aarch64/kernel-features.h
(__ASSUME_DUP3): Do not define.
(__ASSUME_EVENTFD2): Likewise.
(__ASSUME_IN_NONBLOCK): Likewise.
(__ASSUME_O_CLOEXEC): Likewise.
(__ASSUME_PIPE2): Likewise.
(__ASSUME_SIGNALFD4): Likewise.
(__ASSUME_SOCK_CLOEXEC): Likewise.
(__ASSUME_UTIMES): Undefine.
* sysdeps/unix/sysv/linux/alpha/kernel-features.h
(__ASSUME_UTIMES): Do not define.
(__ASSUME_O_CLOEXEC): Likewise.
(__ASSUME_SOCK_CLOEXEC): Likewise.
(__ASSUME_IN_NONBLOCK): Undefine if [__LINUX_KERNEL_VERSION <
0x020621] instead of defining if [__LINUX_KERNEL_VERSION >=
0x020621].
(__ASSUME_PIPE2): Likewise.
(__ASSUME_EVENTFD2): Likewise.
(__ASSUME_SIGNALFD4): Likewise.
[__LINUX_KERNEL_VERSION < 0x020621] (__ASSUME_DUP3): Undefine.
* sysdeps/unix/sysv/linux/arm/kernel-features.h (__ASSUME_UTIMES):
Do not define.
(__ASSUME_EVENTFD2): Likewise.
(__ASSUME_SIGNALFD4): Likewise.
* sysdeps/unix/sysv/linux/hppa/kernel-features.h
(__ASSUME_32BITUIDS): Likewise.
(__ASSUME_TRUNCATE64_SYSCALL): Likewise.
(__ASSUME_IPC64): Likewise.
(__ASSUME_ST_INO_64_BIT): Likewise.
(__ASSUME_GETDENTS64_SYSCALL): Likewise.
[__LINUX_KERNEL_VERSION < 0x030e00] (__ASSUME_UTIMES): Undefine.
* sysdeps/unix/sysv/linux/ia64/kernel-features.h
(__ASSUME_UTIMES): Do not define.
(__ASSUME_PSELECT): Likewise.
(__ASSUME_PPOLL): Likewise.
(__ASSUME_O_CLOEXEC): Likewise.
(__ASSUME_SOCK_CLOEXEC): Likewise.
(__ASSUME_IN_NONBLOCK): Likewise.
(__ASSUME_PIPE2): Likewise.
(__ASSUME_EVENTFD2): Likewise.
(__ASSUME_SIGNALFD4): Likewise.
(__ASSUME_DUP3): Likewise.
* sysdeps/unix/sysv/linux/m68k/kernel-features.h
(__ASSUME_UTIMES): Likewise.
(__ASSUME_O_CLOEXEC): Likewise.
(__ASSUME_SOCK_CLOEXEC): Likewise.
(__ASSUME_IN_NONBLOCK): Likewise.
(__ASSUME_PIPE2): Likewise.
(__ASSUME_EVENTFD2): Likewise.
(__ASSUME_SIGNALFD4): Likewise.
(__ASSUME_DUP3): Likewise.
* sysdeps/unix/sysv/linux/microblaze/kernel-features.h
(__ASSUME_UTIMES): Likewise.
(__ASSUME_O_CLOEXEC): Likewise.
(__ASSUME_SOCK_CLOEXEC): Likewise.
(__ASSUME_IN_NONBLOCK): Likewise.
(__ASSUME_PIPE2): Likewise.
(__ASSUME_EVENTFD2): Likewise.
(__ASSUME_SIGNALFD4): Likewise.
(__ASSUME_DUP3): Likewise.
* sysdeps/unix/sysv/linux/mips/kernel-features.h (__ASSUME_IPC64):
Likewise.
(__ASSUME_UTIMES): Likewise.
(__ASSUME_EVENTFD2): Likewise.
(__ASSUME_SIGNALFD4): Likewise.
* sysdeps/unix/sysv/linux/tile/kernel-features.h
(__ASSUME_O_CLOEXEC): Likewise.
(__ASSUME_SOCK_CLOEXEC): Likewise.
(__ASSUME_IN_NONBLOCK): Likewise.
(__ASSUME_PIPE2): Likewise.
(__ASSUME_EVENTFD2): Likewise.
(__ASSUME_SIGNALFD4): Likewise.
(__ASSUME_DUP3): Likewise.
(__ASSUME_UTIMES): Undefine.
This patch cleans up some symbol versioning code in the ARM port that
exists only as relics of the old-ABI port, which was removed some time
ago.
The minimum symbol version in the ARM port is GLIBC_2.4 (the version
where the EABI port was introduced). Thus, any SHLIB_COMPAT
conditionals where the later version is 2.4 or later are obsolete and
can be removed. In addition, there is no need to set symbol versions
before 2.4 explicitly if the symbols would have a version of 2.4 by
default anyway. This includes most of the entries in
sysdeps/unix/sysv/linux/arm/Versions: those for GLIBC_2.0 are for
libgcc unwind functions that aren't actually in ARM EABI glibc at all,
while those for GLIBC_2.2 and GLIBC_2.3.3 are for functions which for
the old-ABI port may have had versions different from the
architecture-independent default, but where for EABI the default
suffices (both the default and the version in that file map to 2.4, so
the entries in that file do nothing). The GLIBC_2.1 entries are
needed (architecture-specific functions), but it seems less confusing
for those to say GLIBC_2.4, as the actual version those symbols in
fact have.
Various cases in the <fenv.h> functions where a function is defined as
__fe* with an fe* versioned alias are cleaned up just to define fe*
directly, as done e.g. on AArch64. If in future we actually need an
__fe* name for use from C90 functions in libm as discussed recently,
of course we can add one on all architectures and make the fe* name
into a weak alias for that particular function, but for now the __fe*
names aren't needed.
In the case of posix_fadvise64, the __posix_fadvise64_l64 name and
posix_fadvise64 alias are kept as __posix_fadvise64_l64 is used in
posix_fadvise. (For that to be a namespace-clean use, posix_fadvise64
needs to be a *weak* alias not a strong one as at present, but that's
an independent preexisting bug.)
(There remain references to GLIBC_2_2 in
sysdeps/unix/sysv/linux/arm/{msgctl.c,semctl.c,shmctl.c}. As those
files are used by alpha which has a genuine 2.2 version for those
functions, I think those references need to stay as-is.)
Tested that the disassembly of installed shared libraries is unchanged
by this patch (though function names shown in disassembly change to no
longer have @@GLIBC_2.4, now those functions get versioned only by the
version map and not redundantly at assembler time) and that the ABI
tests pass.
* sysdeps/arm/fclrexcpt.c (__feclearexcept): Rename to
feclearexcept. Remove symbol versioning code.
* sysdeps/arm/fegetenv.c (__fegetenv): Rename to fegetenv. Remove
symbol versioning code.
* sysdeps/arm/fesetenv.c (__fesetenv): Rename to fesetenv. Remove
symbol versioning code.
* sysdeps/arm/feupdateenv.c (__feupdateenv): Rename to
feupdateenv. Remove symbol versioning code.
* sysdeps/arm/fgetexcptflg.c (__fegetexceptflag): Rename to
fegetexceptflag. Remove symbol versioning code.
* sysdeps/arm/fsetexcptflg.c (__fesetexceptflag): Rename to
fesetexceptflag. Remove symbol versioning code.
* sysdeps/unix/sysv/linux/arm/Versions (libc): Remove GLIBC_2.0,
GLIBC_2.2 and GLIBC_2.3.3 entries. Change GLIBC_2.1 to GLIBC_2.4.
* sysdeps/unix/sysv/linux/arm/posix_fadvise64.c
(__posix_fadvise64_l32): Remove prototype.
[SHLIB_COMPAT(libc, GLIBC_2_2, GLIBC_2_3_3)]: Remove conditional
code.
This patch does some initial cleanup, following the move to 2.6.32
minimum kernel version, by removing __LINUX_KERNEL_VERSION
conditionals that are now always-true or always-false. In the case of
__ASSUME_ARG_MAX_STACK_BASED, where the conditional used a kernel
version that was itself in a macro, the associated sysconf.c code is
also cleaned up and __ASSUME_ARG_MAX_STACK_BASED removed completely.
Tested x86_64 that disassembly of installed shared libraries is
unchanged by the patch.
* sysdeps/unix/sysv/linux/kernel-features.h [__s390__]
(__ASSUME_UTIMES): Do not condition on kernel version.
(__ASSUME_PSELECT): Define unconditionally.
(__ASSUME_PPOLL): Likewise.
(__ASSUME_ATFCTS): Likewise.
(__ASSUME_SET_ROBUST_LIST): Do not condition on kernel version.
(__ASSUME_COMPLETE_READV_WRITEV): Define unconditionally.
(__ASSUME_FUTEX_LOCK_PI): Do not condition on kernel version.
(__ASSUME_UTIMENSAT): Define unconditionally.
(__ASSUME_PRIVATE_FUTEX): Likewise.
(__ASSUME_FALLOCATE): Likewise.
(__ASSUME_O_CLOEXEC): Likewise.
(__LINUX_ARG_MAX_STACK_BASED_MIN_KERNEL): Remove.
(__ASSUME_ARG_MAX_STACK_BASED): Likewise.
(__ASSUME_ADJ_OFFSET_SS_READ): Define unconditionally.
(__ASSUME_SOCK_CLOEXEC): Do not condition on kernel version.
(__ASSUME_IN_NONBLOCK): Likewise.
(__ASSUME_PIPE2): Likewise.
(__ASSUME_EVENTFD2): Likewise.
(__ASSUME_SIGNALFD4): Likewise.
(__ASSUME_DUP3): Likewise.
[__x86_64__ || __sparc__] (__ASSUME_ACCEPT4_SYSCALL): Likewise.
(__ASSUME_FUTEX_CLOCK_REALTIME): Define unconditionally.
(__ASSUME_AT_RANDOM): Likewise.
(__ASSUME_PREADV): Likewise.
(__ASSUME_PWRITEV): Likewise.
(__ASSUME_REQUEUE_PI): Do not condition on kernel version.
(__ASSUME_F_GETOWN_EX): Define unconditionally.
(__ASSUME_XFS_RESTRICTED_CHOWN): Likewise.
* sysdeps/unix/sysv/linux/sysconf.c (__sysconf)
[!__ASSUME_ARG_MAX_STACK_BASED]: Remove conditional code.
* sysdeps/unix/sysv/linux/alpha/kernel-features.h
(__ASSUME_O_CLOEXEC): Define unconditionally.
(__ASSUME_PSELECT): Do not undefine conditionally.
(__ASSUME_PPOLL): Likewise.
(__ASSUME_ATFCTS): Likewise.
(__ASSUME_SET_ROBUST_LIST): Likewise.
(__ASSUME_UTIMENSAT): Likewise.
(__ASSUME_FDATASYNC): Define unconditionally.
* sysdeps/unix/sysv/linux/arm/kernel-features.h
(__ASSUME_SIGFRAME_V2): Likewise.
)__ASSUME_EVENTFD2): Likewise.
(__ASSUME_SIGNALFD4): Likewise.
(__ASSUME_PSELECT): Do not undefine conditionally.
(__ASSUME_PPOLL): Likewise.
* sysdeps/unix/sysv/linux/ia64/kernel-features.h
(__ASSUME_PSELECT): Define unconditionally.
(__ASSUME_PPOLL): Likewise.
(__ASSUME_O_CLOEXEC): Likewise.
(__ASSUME_SOCK_CLOEXEC): Likewise.
(__ASSUME_IN_NONBLOCK): Likewise.
(__ASSUME_PIPE2): Likewise.
(__ASSUME_EVENTFD2): Likewise.
(__ASSUME_SIGNALFD4): Likewise.
(__ASSUME_DUP3): Likewise.
* sysdeps/unix/sysv/linux/m68k/kernel-features.h
(__ASSUME_O_CLOEXEC): Likewise.
(__ASSUME_SOCK_CLOEXEC): Likewise.
(__ASSUME_IN_NONBLOCK): Likewise.
(__ASSUME_PIPE2): Likewise.
(__ASSUME_EVENTFD2): Likewise.
(__ASSUME_SIGNALFD4): Likewise.
(__ASSUME_DUP3): Likewise.
* sysdeps/unix/sysv/linux/mips/kernel-features.h
(__ASSUME_EVENTFD2): Likewise.
(__ASSUME_SIGNALFD4): Likewise.
(__ASSUME_ACCEPT4_SYSCALL): Likewise.
This patch fixes bug 16064, i386 fenv_t not including SSE state, using
the technique suggested there of storing the state in the existing
__eip field of fenv_t to avoid needing to increase the size of fenv_t
and add new symbol versions. The included testcase, which previously
failed for i386 (but passed for x86_64), illustrates how the previous
state was buggy.
This patch causes the SSE state to be included *to the extent it is on
x86_64*. Where some state should logically be included but isn't for
x86_64 (see bug 16068), this patch does not cause it to be included
for i386 either. The idea is that any patch fixing that bug should
fix it for both x86_64 and i386 at once.
Tested i386 and x86_64. (I haven't tested the case of a CPU without
SSE2 disabling the test.)
[BZ #16064]
* sysdeps/i386/fpu/fegetenv.c: Include <unistd.h>, <ldsodefs.h>
and <dl-procinfo.h>.
(__fegetenv): Save SSE state in envp->__eip if supported.
* sysdeps/i386/fpu/feholdexcpt.c (feholdexcept): Save SSE state in
envp->__eip if supported.
* sysdeps/i386/fpu/fesetenv.c: Include <unistd.h>, <ldsodefs.h>
and <dl-procinfo.h>.
(__fesetenv): Always set __eip, __cs_selector, __opcode,
__data_offset and __data_selector in environment to 0. Set SSE
state if supported.
* sysdeps/x86/fpu/Makefile [$(subdir) = math] (tests): Add
test-fenv-sse.
[$(subdir) = math] (CFLAGS-test-fenv-sse.c): Add -msse2
-mfpmath=sse.
* sysdeps/x86/fpu/test-fenv-sse.c: New file.
Set values for libc_commonpagesize and libc_relro_required for the
ARM port to enable relro by default and suppress a warning at
configure time.
ChangeLog:
2014-05-09 Will Newton <will.newton@linaro.org>
* sysdeps/arm/preconfigure.ac: Set libc_commonpagesize
and libc_relro_required for ARM.
* sysdeps/arm/preconfigure: Regenerate.
Added support for TX lock elision of pthread mutexes on s390 and
s390x. This may improve lock scaling of existing programs on TX
capable systems. The lock elision code is only built with
--enable-lock-elision=yes and then requires a GCC version supporting
the TX builtins. With lock elision default mutexes are elided via
__builtin_tbegin, if the cpu supports transactions. By default lock
elision is not enabled and the elision code is not built.
Add an optimized implementation of strcmp for ARMv7-A cores. This
implementation is significantly faster than the current generic C
implementation, particularly for strings of 16 bytes and longer.
Tested with the glibc string tests for arm-linux-gnueabihf and
armeb-linux-gnueabihf.
The code was written by ARM, who have agreed to assign the copyright
to the FSF for integration into glibc.
ChangeLog:
2014-05-09 Will Newton <will.newton@linaro.org>
* sysdeps/arm/armv7/strcmp.S: New file.
* NEWS: Mention addition of ARMv7 optimized strcmp.
The optimization is achieved by following techniques:
> data alignment [gain from aligned memory access on read/write]
> POWER7 gains performance with loop unrolling/unwinding
[gain by reduction of branch penalty].
> zero padding done by calling optimized memset
This patch changes de default symbol redirection for internal call of
memcpy, memset, memchr, and strlen to the IFUNC resolved ones. The
performance improvement is noticeable in algorithms that uses these
symbols extensible, like the regex functions.
Define FEATURE_INDEX_1 and FEATURE_INDEX_MAX as macros
for use by both assembly and C code. This fixes the
-Wundef error for cases where FEATURE_INDEX_1 was not
defined but used the correct value of 0 for an undefined
macro.
[BZ #16885]
* sysdeps/sparc/sparc64/strcmp.S: Fix end comparison handling when
multiple zero bytes exist at the end of a string.
Reported by Aurelien Jarno <aurelien@aurel32.net>
* string/test-strcmp.c (check): Add explicit test for situations where
there are multiple zero bytes after the first.
lowlevellock.c for arm differs from the generic lowlevellock.c only in
insignificant ways, so can be removed. Happily, this fixes BZ 15119
(unnecessary busy loop in __lll_timedlock_wait on arm).
The notable differences between the arm and generic implementations are:
1) arm __lll_timedlock_wait has a fast path out if futex has been set
to 0 between since the function was called. This seems unlikely to
happen very often, so it seems at worst harmless to lose this fast
path.
2) Some function in arm's lowlevellock.c set futex to 2 if it was 1.
The generic version always sets the futex to 2. As futex can only be
0, 1 or 2 on entry into these functions, the behaviour is equivalent.
(If the futex manages to be 0 on entry then we've just lost another
unlikely fast path out.)
There are no test suite regressions.
Note that hppa and sparc also have their own lowlevellock.c. I believe
hppa can also be removed, so I'll send a separate patch for that
shortly. sparc's seems to be genuinely needed as it uses a different
locking structure.
Also note that the analysis at
https://sourceware.org/ml/libc-ports/2013-02/msg00021.html indicates a
further locking performance bug to fix - I've got a partial patch for
that which I can submit once I've finished testing.
2014-05-01 Bernard Ogden <bernie.ogden@linaro.org>
[BZ #15119]
* sysdeps/unix/sysv/linux/arm/nptl/lowlevellock.c: Remove file.
This patch fixes what I believe to be a bug in the handling of
R_ARM_IRELATIVE RELA relocations. At present, these are handled the
same as REL relocations: i.e. the addend is loaded from the relocation
address. Most of the time this isn't a problem because RELA relocations
aren't used on ARM (GNU/Linux at least) anyway, but it causes problems
with prelink, which uses RELA on all targets for its conflict table.
(Support for ifunc prelinking requires a prelink patch, not yet posted.)
Anyway, this patch works, though I'm not 100% sure if it is correct: I
notice that this code path received attention last year:
https://sourceware.org/ml/libc-ports/2013-07/msg00000.html
I'm not sure under what circumstances that patch would have had an
effect, nor if my patch conflicts with that case.
No regressions using Mentor's usual glibc cross-testing infrastructure.
[BZ #16888]
* sysdeps/arm/dl-machine.h (elf_machine_rela): Fix R_ARM_IRELATIVE
handling.
This patch increases the minimum Linux kernel version for glibc to
2.6.32, as discussed in the thread starting at
<https://sourceware.org/ml/libc-alpha/2014-01/msg00511.html>.
This patch just does the minimal change to arch_minimum_kernel
settings (and LIBC_LINUX_VERSION, which determines the minimum kernel
headers version, as it doesn't make sense for that to be older than
the minimum kernel that can be used at runtime). Followups would be
expected to do, roughly and not necessarily precisely in this order:
* Remove __LINUX_KERNEL_VERSION checks in kernel-features.h files
where those checks are always true / always false for kernels 2.6.32
and above.
* Otherwise simplify/improve conditionals in those files (for example,
where defining once in the main file then undefining in
architecture-specific files makes things clearer than having lots of
separate definitions of the same macro), possibly fixing in the
process cases where a macro should optimally have been defined for a
given architecture but wasn't. (In the review in preparation for
this version increase I checked what the right conditions should be
for all macros in the main kernel-features.h whose definitions there
would have been affected by the increase - but I only fixed that
subset of the issues found where --enable-kernel=2.6.32 would have
caused a kernel feature to be wrongly assumed to be present, not any
cases where a feature is not assumed but could be assumed.)
* Remove conditionals on __ASSUME_* where they can now be taken to be
always-true, and the definitions when the macros are only used in
Linux-specific files.
* Split more architectures out of the main kernel-features.h (like
ex-ports architectures), once various of the architecture
conditionals there have been eliminated so the new
architecture-specific files are no larger than actually necessary.
Tested x86_64.
2014-03-27 Joseph Myers <joseph@codesourcery.com>
[BZ #9894]
* sysdeps/unix/sysv/linux/configure.ac (LIBC_LINUX_VERSION):
Change to 2.6.32.
(arch_minimum_kernel): Change all 2.6.16 settings to 2.6.32.
* sysdeps/unix/sysv/linux/configure: Regenerated.
* sysdeps/unix/sysv/linux/microblaze/configure.ac: Remove file.
* sysdeps/unix/sysv/linux/microblaze/configure: Likewise.
* sysdeps/unix/sysv/linux/tile/configure.ac: Likewise.
* sysdeps/unix/sysv/linux/tile/configure: Likewise.
* README: Update reference to required Linux kernel version.
* manual/install.texi (Linux): Update reference to required Linux
kernel headers version.
* INSTALL: Regenerated.
This patch optimizes the FPSCR update on exception and rounding change
functions by just updating its value if new value if different from
current one. It also optimizes fedisableexcept and feenableexcept by
removing an unecessary FPSCR read.
__int128 was added in GCC 4.6 and __int128_t was added before x86-64
was supported. This patch replaces __int128 with __int128_t so that
the installed bits/link.h can be used with older GCC.
* sysdeps/x86/bits/link.h (La_x86_64_regs): Replace __int128
with __int128_t.
(La_x86_64_retval): Likewise.
The current implementation of setcontext uses rt_sigreturn to restore
the contents of registers. This contrasts with the way most other
architectures implement setcontext:
powerpc64, mips, tile:
Call rt_sigreturn if context was created by a call to a signal handler,
otherwise restore in user code.
powerpc32:
Call swapcontext system call and don't call sigreturn or rt_sigreturn.
x86_64, sparc, hppa, sh, ia64, m68k, s390, arm:
Only support restoring "synchronous" contexts, that is contexts
created by getcontext, and restoring in user code and don't call
sigreturn or rt_sigreturn.
alpha:
Call sigreturn (but not rt_sigreturn) in all cases to do the restore.
The text of the setcontext manpage suggests that the requirement to be
able to restore a signal handler created context has been dropped from
SUSv2:
If the context was obtained by a call to a signal handler, then old
standard text says that "program execution continues with the program
instruction following the instruction interrupted by the signal".
However, this sentence was removed in SUSv2, and the present verdict
is "the result is unspecified".
Implementing setcontext by calling rt_sigreturn unconditionally causes
problems when used with sigaltstack as in BZ #16629. On this basis it
seems that aarch64 is broken and that new ports should only support
restoring contexts created with getcontext and do not need to call
rt_sigreturn at all.
This patch re-implements the aarch64 setcontext function to restore
the context in user code in a similar manner to x86_64 and other ports.
ChangeLog:
2014-04-17 Will Newton <will.newton@linaro.org>
[BZ #16629]
* sysdeps/unix/sysv/linux/aarch64/setcontext.S (__setcontext):
Re-implement to restore registers in user code and avoid
rt_sigreturn system call.
Besides fixing the bugzilla, this also fixes corner-cases where the high
and low double differ greatly in magnitude, and handles a denormal
input without resorting to a fp rescale.
[BZ #16740]
[BZ #16619]
* sysdeps/ieee754/ldbl-128ibm/s_frexpl.c (__frexpl): Rewrite.
* math/libm-test.inc (frexp_test_data): Add tests.
[BZ #15215] This unifies various pthread_once architecture-specific
implementations which were using the same algorithm with slightly different
implementations. It also adds missing memory barriers that are required for
correctness.
This patch saves and restores bound registers in symbol lookup for x86-64:
1. Branches without BND prefix clear bound registers.
2. x86-64 pass bounds in bound registers as specified in MPX psABI
extension on hjl/mpx/master branch at
https://github.com/hjl-tools/x86-64-psABIhttps://groups.google.com/forum/#!topic/x86-64-abi/KFsB0XTgWYc
Binutils has been updated to create an alternate PLT to add BND prefix
when branching to ld.so.
* config.h.in (HAVE_MPX_SUPPORT): New #undef.
* sysdeps/x86_64/configure.ac: Set HAVE_MPX_SUPPORT.
* sysdeps/x86_64/configure: Regenerated.
* sysdeps/x86_64/dl-trampoline.S (REGISTER_SAVE_AREA): New
macro.
(REGISTER_SAVE_RAX): Likewise.
(REGISTER_SAVE_RCX): Likewise.
(REGISTER_SAVE_RDX): Likewise.
(REGISTER_SAVE_RSI): Likewise.
(REGISTER_SAVE_RDI): Likewise.
(REGISTER_SAVE_R8): Likewise.
(REGISTER_SAVE_R9): Likewise.
(REGISTER_SAVE_BND0): Likewise.
(REGISTER_SAVE_BND1): Likewise.
(REGISTER_SAVE_BND2): Likewise.
(_dl_runtime_resolve): Use them. Save and restore Intel MPX
bound registers when calling _dl_fixup.
pathconf(_PC_NAME_MAX) was implemented on top of statfs(). The 32bit
version therefore fails EOVERFLOW if the filesystem blockcount is
sufficiently large.
Most pathconf() queries use statvfs64(), which avoids this issue. This
patch modifies pathconf(_PC_NAME_MAX) to do likewise.
This patch moves the __PTHREAD_SPINS definition to arch specific header
since pthread_mutex_t layout is also arch specific. This leads to no
need to defining __PTHREAD_MUTEX_HAVE_ELISION and thus removing of the
undefined compiler warning.
This patch fixes some powerpc32 and powerpc64 builds with
--disable-multi-arch option along with different --with-cpu=powerN.
It cleanups the Implies directories by removing the multiarch
folder for non multiarch config and also fixing two assembly
implementations: powerpc64/power7/strncat.S that is calling the
wrong strlen; and power8/fpu/s_isnan.S that misses the hidden_def and
weak_alias directives.
This patch makes the configure adds -D_CALL_ELF=1 when compiler does
not define _CALL_ELF (versions before powerpc64le support). It cleans
up compiler warnings on old compiler where _CALL_ELF is not defined
on powerpc64(be) builds.
It does by add a new config.make variable for configure-deduced
CPPFLAGS and accumulate into that (confix-extra-cppflags). It also
generalizes libc_extra_cflags so it accumulates in sysdeps configure
fragmenets.
This patch fixes the powerpc32 optimized nearbyint/nearbyintf bogus
results for FE_DOWNWARD rounding mode. This is due wrong instructions
sequence used in the rounding calculation (two subtractions instead of
adition and a subtraction).
Fixes BZ#16815.
This patch fixes incorrect results from catan and catanh of certain
special inputs in round-downward mode (bug 16799), and incorrect
results of __ieee754_logf (+/-0) in round-downward mode (bug 16800)
that show up through catan/catanh when tested in all rounding modes,
but not directly in the testing for logf because the bug gets hidden
by the wrappers.
Both bugs involve a zero that should be +0 being -0 instead: one
computed as (1-x)*(1+x) in the catan/catanh case, and one as (x-x) in
the logf case. The fixes ensure positive zero is used. Testing of
catan and catanh in all rounding modes is duly enabled.
I expect there are various other bugs in special cases in __ieee754_*
functions that are normally hidden by the wrappers but would show up
for testing with -lieee (or in future with -fno-math-errno if we
replace -lieee and _LIB_VERSION with compile-time redirection to new
*_noerrno symbol names).
Tested x86_64 and x86 and ulps updated accordingly.
[BZ #16799]
[BZ #16800]
* math/s_catan.c (__catan): Avoid passing -0 denominator to atan2
with 0 numerator.
* math/s_catanf.c (__catanf): Likewise.
* math/s_catanh.c (__catanh): Likewise.
* math/s_catanhf.c (__catanhf): Likewise.
* math/s_catanhl.c (__catanhl): Likewise.
* math/s_catanl.c (__catanl): Likewise.
* sysdeps/ieee754/flt-32/e_logf.c (__ieee754_logf): Always divide
by positive zero when computing -Inf result.
* math/libm-test.inc (catan_test): Use ALL_RM_TEST.
(catanh_test): Likewise.
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
This patch fixes bug 16789, incorrect sign of (real part) zero result
from clog and clog10 in round-downward mode, arising from that real
part being computed as 0 - 0. To ensure that an underflow exception
occurred, the code used an underflowing value (the next term in the
series for log1p) in arithmetic computing the real part of the result,
yielding the problematic 0 - 0 computation in some cases even when the
mathematical result would be small but positive. The patch changes
this code to use the math_force_eval approach to ensuring that an
underflowing computation actually occurs. Tests of clog and clog10
are enabled in all rounding modes.
Tested x86_64 and x86 and ulps updated accordingly.
[BZ #16789]
* math/s_clog.c (__clog): Use math_force_eval to ensure underflow
instead of using underflowing value in computing result.
* math/s_clog10.c (__clog10): Likewise.
* math/s_clog10f.c (__clog10f): Likewise.
* math/s_clog10l.c (__clog10l): Likewise.
* math/s_clogf.c (__clogf): Likewise.
* math/s_clogl.c (__clogl): Likewise.
* math/libm-test.inc (clog_test): Use ALL_RM_TEST.
(clog10_test): Likewise.
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
Fix for values near a power of two, and some tidies.
[BZ #16739]
* sysdeps/ieee754/ldbl-128ibm/s_nextafterl.c (__nextafterl): Correct
output when value is near a power of two. Use int64_t for lx and
remove casts. Use decimal rather than hex exponent constants.
Don't use long double multiplication when double will suffice.
* math/libm-test.inc (nextafter_test_data): Add tests.
* NEWS: Add 16739 and 16786 to bug list.
This patch continues fixing __ASSUME_* issues in preparation for
moving to a 2.6.32 minimum kernel version by addressing assumptions on
robust mutex and PI futex support availability. Those assumptions are
bug 9894, but to be clear this patch does not address all the issues
from that bug about wrong version assumptions, only those still
applicable for --enable-kernel=2.6.32 or later (with the expectation
that the move to that minimum kernel will obsolete the other parts of
the bug). The patch is independent of
<https://sourceware.org/ml/libc-alpha/2014-03/msg00585.html>, my other
pending-review patch preparing for the kernel version change; the two
together complete all the changes I believe are needed in preparation
regarding any macro in sysdeps/unix/sysv/linux/kernel-features.h that
would be affected by such a change. (I have not checked the
correctness of macros whose conditions are unaffected by such a
change, or macros only defined in other kernel-features.h files.)
As discussed in that bug, robust mutexes and PI futexes need
futex_atomic_cmpxchg_inatomic to be implemented, in addition to
certain syscalls needed for robust mutexes (and
architecture-independent kernel pieces for all the features in
question). That is, as I understand it, they need
futex_atomic_cmpxchg_inatomic to *work* (not return an ENOSYS error).
The issues identified in my analysis relate to ARM, M68K, MicroBlaze,
MIPS and SPARC.
On ARM, whether futex_atomic_cmpxchg_inatomic works depends on the
kernel configuration. As of 3.13, the condition for *not* working is
CONFIG_CPU_USE_DOMAINS && CONFIG_SMP. As of 2.6.32 it was simply
CONFIG_SMP that meant the feature was not implemented. I don't know
if there are any circumstances in which we can say "we can assume a
userspace glibc binary built with these options will never run on a
kernel with the problematic configuration", but at least for now I'm
just undefining the relevant __ASSUME_* macros for ARM.
On M68K, two of the three macros are undefined for kernels before
3.10, but as far as I can see __ASSUME_FUTEX_LOCK_PI is in the same
group needing futex_atomic_cmpxchg_inatomic support and so should be
undefined as well.
On MicroBlaze the required support was added in 2.6.33.
On MIPS, the support depends on cpu_has_llsc in the kernel - that is,
actual hardware LL/SC support (GCC and glibc for MIPS GNU/Linux rely
on the instructions being supported in some way, but it may be kernel
emulation; futex_atomic_cmpxchg_inatomic doesn't work with that
emulation). The same condition as in GCC for indicating LL/SC support
may not be available is used for undefining the macros in glibc,
__mips == 1 || defined _MIPS_ARCH_R5900. (Maybe we could in fact
desupport MIPS processors without the hardware support in glibc.)
On SPARC, 32-bit kernels don't support futex_atomic_cmpxchg_inatomic;
__arch64__ || __sparc_v9__ is used as the condition for binaries that
won't run on 32-bit kernels.
This patch is not tested beyond the sanity check of an x86_64 build.
[BZ #9894]
* sysdeps/unix/sysv/linux/kernel-features.h
[__sparc__ && !__arch64__ && !__sparc_v9__]
(__ASSUME_SET_ROBUST_LIST): Do not define.
[__sparc__ && !__arch64__ && !__sparc_v9__]
(__ASSUME_FUTEX_LOCK_PI): Likewise.
[__sparc__ && !__arch64__ && !__sparc_v9__] (__ASSUME_REQUEUE_PI):
Likewise.
* sysdeps/unix/sysv/linux/arm/kernel-features.h
(__ASSUME_FUTEX_LOCK_PI): Undefine.
(__ASSUME_REQUEUE_PI): Likewise.
(__ASSUME_SET_ROBUST_LIST): Likewise.
* sysdeps/unix/sysv/linux/m68k/kernel-features.h
[__LINUX_KERNEL_VERSION < 0x030a00] (__ASSUME_FUTEX_LOCK_PI):
Undefine.
* sysdeps/unix/sysv/linux/microblaze/kernel-features.h
[__LINUX_KERNEL_VERSION < 0x020621] (__ASSUME_FUTEX_LOCK_PI):
Likewise.
[__LINUX_KERNEL_VERSION < 0x020621] (__ASSUME_REQUEUE_PI):
Likewise.
[__LINUX_KERNEL_VERSION < 0x020621] (__ASSUME_SET_ROBUST_LIST):
Likewise.
* sysdeps/unix/sysv/linux/mips/kernel-features.h
[__mips == 1 || _MIPS_ARCH_R5900] (__ASSUME_FUTEX_LOCK_PI):
Undefine.
[__mips == 1 || _MIPS_ARCH_R5900] (__ASSUME_REQUEUE_PI): Likewise.
[__mips == 1 || _MIPS_ARCH_R5900] (__ASSUME_SET_ROBUST_LIST):
Likewise.
Continuing the fixes for __ASSUME_* issues in preparation for moving
to a 2.6.32 minimum kernel version, this *untested* patch fixes bug
16648, the definition of __ASSUME_ATFCTS meaning that the futimesat
syscall is assumed for all MicroBlaze kernels despite not being
present until 2.6.33.
__ASSUME_ATFCTS controls conditionals relating to a lot of different
syscalls in Linux-specific code (fstatat64 faccessat fchmodat fchownat
futimesat newfstatat linkat mkdirat openat readlinkat renameat
symlinkat unlinkat mknodat), where whether newfstatat fstatat64
futimesat are used depends on the architecture, as well as controlling
whether openat64_not_cancel_3 is expected to work in
sysdeps/posix/getcwd.c. The assumptions are all OK as of 2.6.32
except for this MicroBlaze case, and it's generally desirable to get
rid of as many of the __ASSUME_ATFCTS conditionals as possible, to
simplify the code (the fallbacks include potential unbounded dynamic
stack allocations). Thus, rather than the simplest approach of
undefining __ASSUME_ATFCTS for older kernels on MicroBlaze, this patch
takes the approach of using the linux-generic implementation of
futimesat for MicroBlaze kernels before 2.6.33 (all such kernels have
the utimensat syscall).
[BZ #16648]
* sysdeps/unix/sysv/linux/microblaze/kernel-features.h
[__LINUX_KERNEL_VERSION >= 0x020621] (__ASSUME_FUTIMESAT): Define.
* sysdeps/unix/sysv/linux/microblaze/futimesat.c: New file.
This patch fixes bug 16348, spurious underflows from x86/x86_64 expl
on arguments close to 0. These implementations effectively use expm1
(on the fractional part of the argument) internally, so resulting in
spurious underflows when the result is very close to 1. For arguments
small enough that the round-to-nearest correct result is 1, this patch
uses 1+x instead.
These implementations are also used for exp10l and so the patch fixes
similar issues there (the 0x1p-67 threshold being small enough to be
correct for exp10l as well as expl). But because of spurious
underflows in other exp10 implementations (bug 16560), the tests
aren't added for exp10 at this point - they can be added when the
other exp10 parts of that bug are fixed.
Tested x86_64 and x86; no ulps updates needed.
[BZ #16348]
* sysdeps/i386/fpu/e_expl.S (IEEE754_EXPL) [!USE_AS_EXPM1L]: Use
1+x for argument with exponent below -67.
* sysdeps/x86_64/fpu/e_expl.S (IEEE754_EXPL) [!USE_AS_EXPM1L]:
Likewise.
* math/auto-libm-test-in: Add more tests of exp.
* math/auto-libm-test-out: Regenerated.
Bug 16198 is x86_64 fegetenv wrongly masking exceptions for which
traps are enabled, because that's a side-effect of the fnstenv
instruction. This patch fixes it to use fldenv immediately after
fnstenv, like the i386 version. Tested x86_64 and x86.
[BZ #16198]
* sysdeps/x86_64/fpu/fegetenv.c (fegetenv): Use fldenv after
fnstenv.
* math/test-fenv-preserve.c: New file.
* math/Makefile (tests): Add test-fenv-preserve.
gen-auto-libm-tests presently allows but does not require underflow
exceptions for results with magnitude in the range (greatest
subnormal, least normal].
In some cases, the magnitude of the exact result is very slightly
above the least normal, but rounding in the implementation results in
it effectively computing an infinite-precision result that is slightly
below the least normal, so raising an underflow exception. This is in
accordance with the documented accuracy goals, but results in
testsuite failures.
This patch changes the logic to allow underflows when the mathematical
result is up to 0.5ulp above the least normal (so in any case where
the round-to-nearest result is the least normal). Ideally underflows
in all these cases would be accepted only when an underflow with the
actual result is consistent with the rounding mode (in FE_TOWARDZERO
mode, a return value of the least normal implies that the
infinite-precision result did not underflow so there should be no
underflow exception, for example), so as to match the documented goals
more precisely - whereas at present the tests for exceptions are
completely independent of the tests of the returned values. (The same
applies to overflow exceptions as well - they too should be checked
for consistency with the result, as in FE_TOWARDZERO mode a result
1ulp below the largest finite value should be inconsistent with an
overflow exception and cause a failure with overflow rather than
simply being considered a 1ulp error when overflow is expected.) But
the present patch at least deals with the cases causing spurious
failures so that (a) certain existing tests no longer need to be
marked as having spurious exceptions (such markings in
auto-libm-test-in end up applying to more cases than just those they
are needed for) and (b) log1p can be tested in all rounding modes
without introducing more such failures. This patch duly moves tests
of log1p to ALL_RM_TEST.
Tested x86_64 and x86 and ulps updated accordingly.
[BZ #16357]
[BZ #16599]
* math/gen-auto-libm-tests.c (fp_format_desc): Add field
min_plus_half.
(fp_formats): Update initializers.
(init_fp_formats): Initialize new field.
(output_for_one_input_case): Allow underflow for results up to
min_plus_half.
* math/libm-test.inc (log1p_test): Use ALL_RM_TEST.
* math/auto-libm-test-in: Don't mark some underflows from asin and
atanh as spurious.
* math/auto-libm-test-out: Regenerated.
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
My recent exp patch introduced warnings about implicit __isinf
declarations in exp because e_exp.c didn't include <math.h>. This
patch fixes this. Because <math.h> can't be included after
<math_private.h> (because of macro definitions of __nan*), it was
necessary to put an include in sysdeps/x86_64/fpu/multiarch/e_exp.c as
well.
Tested x86_64.
* sysdeps/ieee754/dbl-64/e_exp.c: Include <math.h>.
* sysdeps/x86_64/fpu/multiarch/e_exp.c
[HAVE_FMA4_SUPPORT || HAVE_AVX_SUPPORT]: Likewise.
This fixes a bug in the way the results from __nscd_getai are collected:
for every returned result a new entry is first added to the
gaih_addrtuple list, but if that result doesn't match the request this
entry remains uninitialized. So for this non-matching result an extra
result with uninitialized content is returned.
To reproduce (with nscd running):
$ getent ahostsv4 localhost
127.0.0.1 STREAM localhost
127.0.0.1 DGRAM
127.0.0.1 RAW
(null) STREAM
(null) DGRAM
(null) RAW
To reproduce:
# ip li add name dummy0 type dummy
# site_id=$(head -c6 /dev/urandom | od -tx2 -An | tr ' ' ':')
# for ((i = 0; i < 65536; i++)) do
> ip ad ad $(printf fd80$site_id::%04x $i)/128 dev dummy0
> done
# (ulimit -s 900; getent ahosts localhost)
# ip li de dummy0
The dbl-64 version of exp needs round-to-nearest mode for its internal
computations, but that has the consequence of inappropriate
overflowing and underflowing results in other rounding modes. This
patch fixes this by recomputing the relevant results in cases where
the round-to-nearest result overflows to infinity or underflows to
zero (most of the diffs are actually just consequent reindentation).
Tests are enabled in all rounding modes for complex functions using
exp - but not for cexp because it turns out there are bugs causing
spurious underflows for cexp for some tests, which will need to be
fixed separately (I suspect ccos ccosh csin csinh ctan ctanh have
similar bugs, just not shown by the present set of test inputs).
Tested x86_64 and x86 and ulps updated accordingly.
[BZ #16284]
* sysdeps/ieee754/dbl-64/e_exp.c (__ieee754_exp): Use original
rounding mode to recompute results that overflow to infinity or
underflow to zero.
* math/auto-libm-test-in: Don't mark tests as expected to fail for
bug 16284.
* math/auto-libm-test-out: Regenerated.
* math/libm-test.inc (ccos_test): Use ALL_RM_TEST.
(ccosh_test): Likewise.
(csin_test_data): Use plus_oflow.
(csin_test): Use ALL_RM_TEST.
(csinh_test_data): Use plus_oflow.
(csinh_test): Use ALL_RM_TEST.
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
This patch fixes -Wundef warnings related to the _ABI* macros on MIPS.
GCC predefines only the _ABI* macro related to the ABI actually in
use, meaning that a conditional such as "#if _MIPS_SIM == _ABI64" is
true only for the ABI in question (all the macros are nonzero), but
produces a -Wundef warning for the other ABIs. The normal approach to
using these macros is to include <sgidefs.h>, which ensures that all
three _ABI* macros are defined rather than just one; this patch does
so in the places that caused warnings (the bulk of the warnings
arising from <bits/wordsize.h>). Tested that the warnings are fixed.
* sysdeps/mips/bits/wordsize.h: Include <sgidefs.h>.
* sysdeps/unix/sysv/linux/mips/getrlimit64.c: Likewise.
* sysdeps/unix/sysv/linux/mips/setrlimit64.c: Likewise.
According to ISO C Annex F, log (1) should be +0 in all rounding
modes, but some implementations in glibc wrongly return -0 in
round-downward mode (mapping to log1p (x - 1) is problematic because 1
- 1 is -0 in round-downward mode, and log1p (-0) is -0). This patch
fixes this. (It helps with some implementations of other functions
such as acosh, log2 and log10 that call out to log, but not enough to
enable all-rounding-modes testing for those functions without further
fixes to other implementations of them.)
Tested x86_64 and x86 and ulps updated accordingly, and did spot tests
for mips64 for the ldbl-128 fix, and i586 for the sysdeps/i386/fpu
implementations shadowed by those in sysdeps/i386/i686/fpu.
[BZ #16731]
* sysdeps/i386/fpu/e_log.S (__ieee754_log): Take absolute value
when x - 1 is zero.
* sysdeps/i386/fpu/e_logf.S (__ieee754_logf): Likewise.
* sysdeps/i386/fpu/e_logl.S (__ieee754_logl): Likewise.
* sysdeps/i386/i686/fpu/e_logl.S (__ieee754_logl): Likewise.
* sysdeps/ieee754/dbl-64/e_log.c (__ieee754_log): Return +0 when
argument is 1.
* sysdeps/ieee754/ldbl-128/e_logl.c (__ieee754_logl): Likewise.
* sysdeps/x86_64/fpu/e_logl.S: Take absolute value when x - 1 is
zero.
* math/libm-test.inc (log_test): Use ALL_RM_TEST.
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
This patch add an optimized strpbrk for POWER7 by using a different
algorithm than default implementation: it constructs a table based on
the 'accept' argument and use this table to check for any occurance on
the input string. The idea is similar as x86_64 uses.
For PowerPC some tunings were added, such as unroll loops and memory
clear using VSX instructions.
This patch makes libm-test.inc tests of most functions use ALL_RM_TEST
unless there was some reason to defer that change for a particular
function.
I started out planning to defer the change for pow (bug 16315), cexp /
ccos / ccosh / csin / csinh (likely fallout from exp, bug 16284) and
cpow (exact expectations for signs of exact zero results not wanted).
Testing on x86_64 and x86 showed additional failures for acosh, cacos,
catan, catanh, clog, clog10, jn, log, log10, log1p, log2, tgamma, yn,
so making the change for those functions was deferred as well, pending
investigation to show which of these represent distinct bugs (some
such bugs may already be filed) and appropriate fixing / XFAILing.
Failures include wrong signs of zero results, errors slightly above
the 9ulp bound (in such cases it may make sense for functions to set
round-to-nearest internally to reduce error accumulation), large
errors and incorrect overflow/underflow for the rounding mode (with
consequent missing errno settings in some cases). It's possible some
could be issues with test expectations, though I didn't notice any
that were obviously like that (I added NO_TEST_INLINE for cases that
were failing for ildoubl on x86 and where it seemed reasonable for
them to fail for the fast-math inlines).
There may of course be failures on other architectures for functions
that didn't fail on x86_64 or x86, in which case the usual rule
applies: file a bug (preferably identifying the underlying problem
function, in cases where function A calls function B and a problem
with function B may present in the test results for function A) if not
already in Bugzilla then fix or XFAIL.
Tested x86_64 and x86 and ulps updated accordingly.
* math/libm-test.inc (asinh_test): Use ALL_RM_TEST.
(atan_test): Likewise.
(atanh_test_data): Use NO_TEST_INLINE for two tests.
(atanh_test): Use ALL_RM_TEST.
(atan2_test_data): Likewise.
(cabs_test): Likewise.
(cacosh_test): Likewise.
(carg_test): Likewise.
(casin_test): Likewise.
(casinh_test): Likewise.
(cbrt_test): Likewise.
(csqrt_test): Likewise.
(erf_test): Likewise.
(erfc_test): Likewise.
(pow10_test): Likewise.
(exp2_test): Likewise.
(hypot_test): Likewise.
(j0_test): Likewise.
(j1_test): Likewise.
(lgamma_test): Likewise.
(gamma_test): Likewise.
(sincos_test): Likewise.
(tanh_test): Likewise.
(y0_test): Likewise.
(y1_test): Likewise.
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
This patch add a optimized strcspn for POWER7 by using a different
algorithm than default implementation: it constructs a table based on
the 'accept' argument and use this table to check for any occurance
on the input string. The idea is similar as x86_64 uses.
For PowerPC some tunings were added, such as unroll loops and align
stack memory to table to 16 bytes (so VSX clean can ran without
alignment issues).
Reviewing (for all architectures, with a baseline kernel version of
2.6.32) the kernel support for features for which __ASSUME_* macros
would be affected by a move to 2.6.32 as minimum kernel version showed
up that __ASSUME_PREADV and __ASSUME_PWRITEV were wrongly defined for
MicroBlaze (despite the corresponding syscall table entries not being
wired up in the kernel) and Alpha for 2.6.30 and above (although the
support on Alpha was added in 2.6.33). This patch makes the
kernel-features.h files undefine those macros for appropriate
versions.
[BZ #16649]
* sysdeps/unix/sysv/linux/alpha/kernel-features.h
[__LINUX_KERNEL_VERSION < 0x020621] (__ASSUME_PREADV): Undefine.
[__LINUX_KERNEL_VERSION < 0x020621] (__ASSUME_PWRITEV): Likewise.
* sysdeps/unix/sysv/linux/microblaze/kernel-features.h
(__ASSUME_PREADV): Undefine.
(__ASSUME_PWRITEV): Likewise.
This comment appears to have been copied from the ARM port where it
makes more sense.
2014-03-18 Will Newton <will.newton@linaro.org>
* sysdeps/unix/sysv/linux/aarch64/sysdep.h: Remove
inaccurate comment.
ChangeLog:
2014-03-17 Will Newton <will.newton@linaro.org>
* sysdeps/generic/math_private.h: Check whether
HAVE_RM_CTX is defined with #ifdef rather
than #if.
ChangeLog:
2014-03-17 Will Newton <will.newton@linaro.org>
* sysdeps/generic/ldsodefs.h: Check whether
HP_SMALL_TIMING_AVAIL is defined with #ifdef rather
than #if.
The roundl assembly implementation
(sysdeps/powerpc/powerpc64/fpu/s_roundl.S)
returns wrong results for some inputs where first double is a exact
integer and the precision is determined by second long double.
Checking on implementation comments and history, I am very confident the
assembly implementation was based on a version before commit
5c68d40169 that fixes BZ#2423 (Errors in
long double (ldbl-128ibm) rounding functions in glibc-2.4).
By just removing the implementation and make the build select
sysdeps/ieee754/ldbl-128ibm/s_roundl.c instead fixes the failing math.
This fixes 16707.
