Fix yn overflow handling in non-default rounding modes (bug 16561, bug 16562).

This patch fixes bugs 16561 and 16562, bad results of yn in overflow
cases in non-default rounding modes, both because an intermediate
overflow in the recurrence does not get detected if the result is not
an infinity and because an overflowing result may occur in the wrong
sign.  The fix is to set FE_TONEAREST mode internally for the parts of
the function where such overflows can occur (which includes the call
to y1 - where yn is used to compute a Bessel function of order -1,
negating the result of y1 isn't correct for overflowing results in
directed rounding modes) and then compute an overflowing value in the
original rounding mode if the to-nearest result was an infinity.

Tested x86_64 and x86 and ulps updated accordingly.  Also tested for
mips64 and powerpc32 to test the ldbl-128 and ldbl-128ibm changes.

(The tests for these bugs were added in my previous y1 patch, so the
only thing this patch has to do with the testsuite is enable yn
testing in all rounding modes.)

	[BZ #16561]
	[BZ #16562]
	* sysdeps/ieee754/dbl-64/e_jn.c: Include <float.h>.
	(__ieee754_yn): Set FE_TONEAREST mode internally and then
	recompute overflowing results in original rounding mode.
	* sysdeps/ieee754/flt-32/e_jnf.c: Include <float.h>.
	(__ieee754_ynf): Set FE_TONEAREST mode internally and then
	recompute overflowing results in original rounding mode.
	* sysdeps/ieee754/ldbl-128/e_jnl.c: Include <float.h>.
	(__ieee754_ynl): Set FE_TONEAREST mode internally and then
	recompute overflowing results in original rounding mode.
	* sysdeps/ieee754/ldbl-128ibm/e_jnl.c: Include <float.h>.
	(__ieee754_ynl): Set FE_TONEAREST mode internally and then
	recompute overflowing results in original rounding mode.
	* sysdeps/ieee754/ldbl-96/e_jnl.c: Include <float.h>.
	(__ieee754_ynl): Set FE_TONEAREST mode internally and then
	recompute overflowing results in original rounding mode.
	* sysdeps/i386/fpu/fenv_private.h [!__SSE2_MATH__]
	(libc_feholdsetround_ctx): New macro.
	* math/libm-test.inc (yn_test): Use ALL_RM_TEST.
	* sysdeps/i386/fpu/libm-test-ulps: Update.
	* sysdeps/x86_64/fpu/libm-test-ulps : Likewise.
Remove relro configure test.

This patch removes the configure test for working -z relro.

The use of -z relro in Makeconfig became unconditional with

commit 2e6ab1df44c412bb9d30b26a4d8a679150a7e375
Author: Ulrich Drepper <drepper@redhat.com>
Date:   Sat Oct 28 06:44:04 2006 +0000

    Remove conditional code which now is unnecessary.

(commit reference from git://repo.or.cz/glibc/history), so since then
the configure test has not controlled anything about how glibc is
built - simply about whether configure succeeds and allows a build to
be attempted.  The test for whether the option did something useful
(as opposed to whether it exists - which we can certainly just assume
by now) was originally added in
<https://sourceware.org/ml/libc-hacker/2004-09/msg00069.html> to
disable the option in a case when it did nothing useful on ia64 (as a
result of something deliberate in the linker on ia64).  Since 2006
that disabling has been of no effect, and given that the current test
does not set libc_relro_required for ia64, it does nothing whatever
useful for the original motivating case.  Also at around the same time
in 2006 the test was made to give an error for missing or broken -z
relro support on various architectures.

So effectively all the test does now is verify that, on certain
architectures, the linker has not been changed deliberately to make
the option ineffective.  I see no apparent reason why such a change
should be expected, or why the build should be stopped if it were to
be made (any more than we disallow build on ia64); I think we can
trust binutils patch review to point out the consequences of any
change to COMMONPAGESIZE setting.  The only thing that might now make
sense would be disabling the -z relro use on an architecture-specific
basis if there were an architecture-specific reason to consider that
to make sense; it would be for the ia64 maintainer to decide if that
makes sense for ia64 at present, but I think that could be done
through sysdeps Makefiles - no special configure tests needed.

Tested for x86_64 that this patch makes no change to the installed
shared libraries.

Together with
<https://sourceware.org/ml/libc-alpha/2014-06/msg00788.html> (pending
review) this substantially eliminates architecture-specific cases from
architecture-independent configure.ac files.  There remains an i386
case in sysdeps/mach/hurd/configure.ac that should properly move to
the i386 subdirectory.  (There are also OS-specific cases outside
OS-specific directories; in principle I think should should also
move.)

	* configure.ac (libc_commonpagesize): Remove variable.
	(libc_relro_required): Likewise.
	(libc_cv_z_relro): Remove configure test.
	* configure: Regenerated.
	* sysdeps/aarch64/preconfigure (libc_commonpagesize): Do not set
	variable.
	(libc_relro_required): Likewise.
	* sysdeps/alpha/preconfigure (libc_commonpagesize): Likewise.
	(libc_relro_required): Likewise.
	* sysdeps/arm/preconfigure.ac (libc_commonpagesize): Likewise.
	(libc_relro_required): Likewise.
	* sysdeps/arm/preconfigure: Regenerated.
	* sysdeps/ia64/preconfigure: Remove file.
	* sysdeps/tile/preconfigure (libc_commonpagesize): Do not set
	variable.
	(libc_relro_required): Likewise.
Correctly report nscd child process status (BZ #17092)

The nscd parent process returns the result of a `wait' call rather
than the exit status of the child it waits for. These two aren't
exactly the same. In my case (and probably on most machines), the exit
status is in the 2nd LSB of the result of `wait', and so:

e.g. if the nscd child process returns 1, the parent returns 1 << 8,
which Bash happily reports as 0.
MIPS: Consolidate NPTL/non versions of vfork
MIPS: Consolidate nptl/ subdirectories under linux/...
Remove shlib-versions ABI names support.

shlib-versions files can contain ABI lines that map triplets to a
canonical ABI name.  This name was once used for various purposes
where test baseline files for different ABIs went in a single
directory; now these purposes use sysdeps files, generation of headers
which have per-ABI variants uses abi-variants and related Makefile
variables and the shlib-versions ABI names are unused.  This patch
duly removes those lines and associated build system support for them.

Tested for x86_64 (both a full testsuite run and confirming the
installed shared libraries are unchanged by the patch).

	* Makeconfig ($(common-objpfx)soversions.mk): Do not generate
	abi-name definition.
	* scripts/soversions.awk: Do not handle or generate ABI lines.
	* shlib-versions: Remove ABI entries.
	* sysdeps/powerpc/nofpu/shlib-versions: Remove file.
	* sysdeps/x86_64/x32/shlib-versions: Remove ABI entry.
Fix Wundef warning for MEMCPY_OK_FOR_FWD_MEMMOVE

Define MEMCPY_OK_FOR_FWD_MEMMOVE in memcopy.h and let arch-specific
implementations of that file override the value if necessary.  This
override is only useful for tile and moving this macro to memcopy.h
allows us to remove the tile-specific memmove.c.
Sync up mktime with gnulib

From the gnulib commit log:

commit e2646b0c6b5acda25e9ffeb4c12a5513a1e3b5ac
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Fri Jun 27 11:35:44 2014 -0700

    mktime: merge #if/#ifdef usage from glibc

    * lib/mktime.c: Use "#if defined DEBUG && DEBUG", not "#if DEBUG",
    as that works with both Glibc's and Gnulib's style.
    See thread starting at Siddhesh Poyarekar's bug report at:
    http://lists.gnu.org/archive/html/bug-gnulib/2014-06/msg00102.html