Architectures which don't use hp-timing-common.h don't include <signal.h>
via <sys/param.h>.

The padding bytes in the statsdata struct are not initialized, due to
which valgrind throws a warning:

==11384== Memcheck, a memory error detector
==11384== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==11384== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==11384== Command: nscd -d
==11384==
Fri 25 Apr 2014 10:34:53 AM CEST - 11384: handle_request: request received (Version = 2) from PID 11396
Fri 25 Apr 2014 10:34:53 AM CEST - 11384:       GETSTAT
==11384== Thread 6:
==11384== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==11384==    at 0x4E4ACDC: send (in /lib64/libpthread-2.12.so)
==11384==    by 0x11AF6B: send_stats (in /usr/sbin/nscd)
==11384==    by 0x112F75: nscd_run_worker (in /usr/sbin/nscd)
==11384==    by 0x4E439D0: start_thread (in /lib64/libpthread-2.12.so)
==11384==    by 0x599AB6C: clone (in /lib64/libc-2.12.so)
==11384==  Address 0x15708395 is on thread 6's stack

Fix the warning by initializing the structure.

This is because of alignment issues in the sem_t support.
tilegx32 does in fact support 64-bit atomics and we will need
to revisit this after the 2.21 freeze.

This patch disables use of 64-bit atomics for MIPS n32 to fix the
problems with unaligned semaphores.

Before 64-bit atomics are used for anything for which such alignment
issues do not arise, and before the addition of any new ILP32 ports
with 64-bit semaphores for which the ABI can be set to have the
greater alignment (AARCH64?), a better approach will need to be
established that allows architectures to declare their 64-bit atomics
availability accurately, without doing so causing inappropriate use of
such atomics on unaligned semaphores.

Tested for MIPS n32 that this fixes the nptl/tst-sem3 failure.

	* sysdeps/mips/bits/atomic.h [_MIPS_SIM == _ABIN32]
	(__HAVE_64B_ATOMICS): Define to 0.

This patch fixes a bug introduced by 18f2945ae9216cfc, where it optimizes
the FPSCR set by just issuing a mtfs instruction if new flag is different
from older one.  The issue is a typo, where the new flag should the the
new value, instead of the old one.

It fixes BZ#17885.

Some powerpc64 processors (e5500 core for instance) does not provide the
fsqrt instruction, however current check to use in math_private.h is
__WORDSIZE and _ARCH_PWR4 (ISA 2.02).  This is patch change it to use
the compiler flag _ARCH_PPCSQ (which is the same condition GCC uses to
decide whether to generate fsqrt instruction).

It fixes BZ#16576.