This patch implements a requirement of binutils >= 2.25 (up from 2.22)
to build glibc. Tests for 2.24 or later on x86_64 and s390 are
removed. It was already the case, as indicated by buildbot results,
that 2.24 was too old for building tests for 32-bit x86 (produced
internal linker errors linking elf/tst-gnu2-tls1mod.so). I don't know
if any configure tests for binutils features are obsolete given the
increased version requirement.
Tested for x86_64.
* configure.ac (AS): Require binutils 2.25 or later.
(LD): Likewise.
* configure: Regenerated.
* sysdeps/s390/configure.ac (AS): Remove version check.
* sysdeps/s390/configure: Regenerated.
* sysdeps/x86_64/configure.ac (AS): Remove version check.
* sysdeps/x86_64/configure: Regenerated.
* manual/install.texi (Tools for Compilation): Document
requirement for binutils 2.25 or later.
* INSTALL: Regenerated.
On s390 feraiseexcept (FE_OVERFLOW|FE_UNDERFLOW) sets FE_INEXACT, too.
This patch uses z196 zarch load rounded instruction which can suppress
FE_INEXACT exception if gcc has z196 support in used configuration.
Otherwise FE_INEXACT flag is set as before. The gcc support is tested
in a new configure-check.
A comment in fsetexcptflg.c is corrected as new exceptions are not
executed with the next floating-point instruction if fpc is set with
_FPU_SETCW macro. It seems the comment was copied e.g. from
sysdeps/x86_64/fpu/fsetexcptflg.c file.
ChangeLog:
* config.h.in (HAVE_S390_MIN_Z196_ZARCH_ASM_SUPPORT):
New undefine.
* sysdeps/s390/configure.ac: Add test for z196 zarch support.
* sysdeps/s390/configure: Regenerated.
* sysdeps/s390/fpu/fraiseexcpt.c (__feraiseexcept): Use ledbra
instruction for raising over-/underflow if z196 zarch is supported
by default.
* sysdeps/s390/fpu/fsetexcptflg.c (fesetexceptflag):
Correct comment.
The S390 specific test checks if the gcc has support for vector registers
by compiling an inline assembly which clobbers vector registers.
On success the macro HAVE_S390_VX_GCC_SUPPORT is defined.
This macro can be used to determine if e.g. clobbering vector registers
is allowed or not.
ChangeLog:
* config.h.in (HAVE_S390_VX_GCC_SUPPORT): New macro undefine.
* sysdeps/s390/configure.ac: Add test for S390 vector register
support in gcc.
* sysdeps/s390/configure: Regenerated.
The S390 specific test checks if the assembler has support for the new z13
vector instructions by compiling a vector instruction. The .machine and
.machinemode directives are needed to compile the vector instruction without
-march=z13 option on 31/64 bit.
On success the macro HAVE_S390_VX_ASM_SUPPORT is defined. This macro is used
to determine if the optimized functions can be build without compile errors.
If the used assembler lacks vector support, then a warning is dumped while
configuring and only the common code functions are build.
The z13 instruction support was introduced in
"[Committed] S/390: Add support for IBM z13."
(https://sourceware.org/ml/binutils/2015-01/msg00197.html)
ChangeLog:
* config.h.in (HAVE_S390_VX_ASM_SUPPORT): New macro undefine.
* sysdeps/s390/configure.ac: Add test for S390 vector instruction
assembler support.
* sysdeps/s390/configure: Regenerated.
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.
