This simplifies the code because it is not necessary to propagate the
temporary h_errno value to the thread-local variable. It also increases
compatibility with NSS modules which update only one of the two places.
Joseph Myers [Tue, 22 Aug 2017 00:30:51 +0000 (00:30 +0000)]
Fix position of tests-unsupported definition in assert/Makefile.
tests-unsupported has to be defined before the inclusion of Rules in a
subdirectory Makefile; otherwise it is ineffective. This patch fixes
the ordering in assert/Makefile, where a recent test addition put
tests-unsupported too late (resulting in build failures when the C++
compiler was missing or broken, and thereby showing up the unrelated
bug 21987).
Incidentally, I don't see why these tests depend on
$(have-cxx-thread_local) rather than just a working C++ compiler.
Tested in such a configuration (broken compiler/libstdc++) with
build-many-glibcs.py.
Provide a C++ version of iszero that does not use __MATH_TG (bug 21930)
When signaling nans are enabled (with -fsignaling-nans), the C++ version
of iszero uses the fpclassify macro, which is defined with __MATH_TG.
However, when support for float128 is available, __MATH_TG uses the
builtin __builtin_types_compatible_p, which is only available in C mode.
This patch refactors the C++ version of iszero so that it uses function
overloading to select between the floating-point types, instead of
relying on fpclassify and __MATH_TG.
Tested for powerpc64le, s390x, x86_64, and with build-many-glibcs.py.
[BZ #21930]
* math/math.h [defined __cplusplus && defined __SUPPORT_SNAN__]
(iszero): New C++ implementation that does not use
fpclassify/__MATH_TG/__builtin_types_compatible_p, when
signaling nans are enabled, since __builtin_types_compatible_p
is a C-only feature.
* math/test-math-iszero.cc: When __HAVE_DISTINCT_FLOAT128 is
defined, include ieee754_float128.h for access to the union and
member ieee854_float128.ieee.
[__HAVE_DISTINCT_FLOAT128] (do_test): Call check_float128.
[__HAVE_DISTINCT_FLOAT128] (check_float128): New function.
* sysdeps/powerpc/powerpc64le/Makefile [subdir == math]
(CXXFLAGS-test-math-iszero.cc): Add -mfloat128 to the build
options of test-math-zero on powerpc64le.
Fix the C++ version of issignaling when __NO_LONG_DOUBLE_MATH is defined
When __NO_LONG_DOUBLE_MATH is defined, __issignalingl is not available,
thus issignaling with long double argument should call __issignaling,
instead.
Tested for powerpc64le.
* math/math.h [defined __cplusplus] (issignaling): In the long
double case, call __issignalingl only if __NO_LONG_DOUBLE_MATH
is not defined. Call __issignaling, otherwise.
Provide a C++ version of issignaling that does not use __MATH_TG
The macro __MATH_TG contains the logic to select between long double and
_Float128, when these types are ABI-distinct. This logic relies on
__builtin_types_compatible_p, which is not available in C++ mode.
On the other hand, C++ function overloading provides the means to
distinguish between the floating-point types. The overloading
resolution will match the correct parameter regardless of type
qualifiers, i.e.: const and volatile.
Tested for powerpc64le, s390x, and x86_64.
* math/math.h [defined __cplusplus] (issignaling): Provide a C++
definition for issignaling that does not rely on __MATH_TG,
since __MATH_TG uses __builtin_types_compatible_p, which is only
available in C mode.
(CFLAGS-test-math-issignaling.cc): New variable.
* math/Makefile [CXX] (tests): Add test-math-issignaling.
* math/test-math-issignaling.cc: New test for C++ implementation
of type-generic issignaling.
* sysdeps/powerpc/powerpc64le/Makefile [subdir == math]
(CXXFLAGS-test-math-issignaling.cc): Add -mfloat128 to the build
options of test-math-issignaling on powerpc64le.
Do not use __builtin_types_compatible_p in C++ mode (bug 21930)
The logic to define isinf for float128 depends on the availability of
__builtin_types_compatible_p, which is only available in C mode,
however, the conditionals do not check for C or C++ mode. This lead to
an error in libstdc++ configure, as reported by bug 21930.
This patch adds a conditional for C mode in the definition of isinf for
float128. No definition is provided in C++ mode, since libstdc++
headers undefine isinf.
Tested for powerpc64le (glibc test suite and libstdc++-v3 configure).
[BZ #21930]
* math/math.h (isinf): Check if in C or C++ mode before using
__builtin_types_compatible_p, since this is a C mode feature.
powerpc: Restrict xssqrtqp operands to Vector Registers (bug 21941)
POWER ISA 3.0 introduces the xssqrtqp instructions, which expects
operands to be in Vector Registers (Altivec/VMX), even though this
instruction belongs to the Vector-Scalar Instruction Set.
In GCC's Extended Assembly for POWER, the 'wq' register constraint is
provided for use with IEEE 754 128-bit floating-point values. However,
this constraint does not limit the register allocation to Vector
Registers (Altivec/VMX) and could assign a Vector-Scalar Register (VSX)
to the operands of the instruction.
This patch changes the register constraint used in sqrtf128 from 'wq' to
'v', in order to request a Vector Register (Altivec/VMX) for use with
the xssqrtqp instruction.
Tested for powerpc64le and --with-cpu=power9.
[BZ #21941]
* sysdeps/powerpc/fpu/math_private.h (__ieee754_sqrtf128): Since
xssqrtqp requires operands to be in Vector Registers
(Altivec/VMX), replace the register constraint 'wq' with 'v'.
* sysdeps/powerpc/powerpc64le/power9/fpu/e_sqrtf128.c
(__ieee754_sqrtf128): Likewise.
posix: Set p{read,write}v2 to return ENOTSUP (BZ#21780)
Different than other architectures hppa-linux-gnu define different values
for ENOTSUP and EOPNOTSUPP, where the later is a Linux specific one.
This leads to tst-preadwritev{64}v2 tests failures:
$ ./testrun.sh misc/tst-preadvwritev2
error: tst-preadvwritev2-common.c:35: preadv2 failure did not set errno to ENOTSUP (223)
error: 1 test failures
The straightforward fix is to return the POSIX defined ENOTSUP on all
p{read,write}v{64}v2 implementations instead of Linux specific one.
Checked on x86_64-linux-gnu and the tst-preadwritev{64}v2 on
hppa-linux-gnu (although due the installed kernel on my testing system
the pwritev{64}v2 with an invalid flag still fails due a known kernel
issue [1]).
since xgetbv takes much more cycles than single cycle operations like
vpord/vvpcmpeq/ptest. _dl_runtime_resolve_opt should be used only with
AVX512 where AVX512 instructions lead to lower CPU frequency on Skylake
server.
[BZ #21871]
* sysdeps/x86/cpu-features.c (init_cpu_features): Set
bit_arch_Use_dl_runtime_resolve_opt only with AVX512F.
Aurelien Jarno [Thu, 3 Aug 2017 22:35:48 +0000 (22:35 +0000)]
Fix the return type of the getentropy stub
The return type of the getentropy stub is wrongly defined as ssize_t,
while both the <sys/random.h> header and the Linux implementation
define it as int. This patch fixes that.
Carlos O'Donell [Sat, 29 Jul 2017 04:02:03 +0000 (00:02 -0400)]
mutex: Fix robust mutex lock acquire (Bug 21778)
65810f0ef05e8c9e333f17a44e77808b163ca298 fixed a robust mutex bug but
introduced BZ 21778: if the CAS used to try to acquire a lock fails, the
expected value is not updated, which breaks other cases in the loce
acquisition loop. The fix is to simply update the expected value with
the value returned by the CAS, which ensures that behavior is as if the
first case with the CAS never happened (if the CAS fails).
This is a regression introduced in the last release.
Tested on x86_64, i686, ppc64, ppc64le, s390x, aarch64, armv7hl.
microblaze: Resolve non-relocatable branch in pt-vfork.S (BZ#21779)
The relative branch directly to __libc_vfork results in an relocation
that cannot be resolved. Specifically a R_MICROBLAZE_64_PCREL relocation
is created for this branch, however for MicroBlaze R_MICROBLAZE_64_PCREL
type relocations symbols are not resolved. Additionally due to the
branch being located in the .text section the instruction cannot be
rewritten as the section is not writable, and causes a segfault at
runtime when loading libpthread.
To resolve this issue, ensure the branch is done using PLT. This removes
the need to modify the instruction and trades the R_MICROBLAZE_64_PCREL
for a more common R_MICROBLAZE_JUMP via the PLT.
[BZ #21779]
* sysdeps/unix/sysv/linux/microblaze/pt-vfork.S: Branch using PLT.
Carlos O'Donell [Fri, 28 Jul 2017 04:22:44 +0000 (00:22 -0400)]
rwlock: Fix explicit hand-over (bug 21298)
Without this fix, the rwlock can fail to execute the explicit hand-over
in certain cases (e.g., empty critical sections that switch quickly between
read and write phases). This can then lead to errors in how __wrphase_futex
is accessed, which in turn can lead to deadlocks.
Mike FABIAN [Thu, 27 Jul 2017 09:04:38 +0000 (11:04 +0200)]
Minor improvements to new az_IR locale
* locales/az_IR (LC_MESSAGES): Improve yesexpr and noexpr.
* locales/az_IR (LC_ADDRESS): Fix typo in comment and
use the individual iso-639-3 code for South Azerbaijani
"azb" in lang_term.
* locales/az_IR (LC_NAME): Improve readability of name_fmt in source.
Rical Jasan [Tue, 20 Jun 2017 13:39:27 +0000 (06:39 -0700)]
manual: Refactor documentation of CHAR_BIT.
This single-@item @table is better defined with @deftypevr, since the
CHAR_BIT macro has @standards (being declared in a header), and @items
in @tables are not considered annotatable. Using @deftypevr
automatically includes the macro in the Variable and Constant Macro
Index and ensures its inclusion the Summary of Library Facilities.
@deftypevr is used to record the type of the macro so that it also
appears in the Summary.
The description is updated to mention a later POSIX requirement that
this macro have the value 8.
* manual/lang.texi (CHAR_BIT): Convert from an @table to an
@deftypevr. Change standard from ISO to C90. Mention the
POSIX.1-2001 requirement of the value 8.
Indian scripts: More fixes after the recent import.
After the recent import of month names from CLDRv31 (bug 21217,
commit c853f14) an import of abbreviated month names is also needed
to make sure they match the full forms.
In case of kok_IN CLDR does not provide the abbreviated month names
explicitly but uses full month names in such cases so abmon section
has been copied from mon.
Maithili which is an official language not only in India but in Nepal as well.
https://en.wikipedia.org/wiki/Maithili_language
Reference is taken form mai_IN.
[BZ #21835]
* localedata/locales/mai_NP: New file.
* localedata/SUPPORTED: Add mai_NP/UTF-8.
tunables: Use direct syscall for access (BZ#21744)
The function maybe_enable_malloc_check, which is called by
__tunables_init, calls __access_noerrno. It isn't problem when
symbol is is in ld.so, which has a special version of __access_noerrno
without stack protector. But when glibc is built with stack protector,
maybe_enable_malloc_check in libc.a can't call the regular version of
__access_noerrno with stack protector.
This patch changes how Linux defines the __access_noerrno to be an
inline call instead and thus preventing defining different build
rules for ld/static and shared.
H.J. Lu <hongjiu.lu@intel.com>
Adhemerval Zanella <adhemerval.zanella@linaro.org>
H.J. Lu [Mon, 24 Jul 2017 13:06:08 +0000 (06:06 -0700)]
Avoid accessing corrupted stack from __stack_chk_fail [BZ #21752]
__libc_argv[0] points to address on stack and __libc_secure_getenv
accesses environment variables which are on stack. We should avoid
accessing stack when stack is corrupted.
This patch also renames function argument in __fortify_fail_abort
from do_backtrace to need_backtrace to avoid confusion with do_backtrace
from enum __libc_message_action.
[BZ #21752]
* debug/fortify_fail.c (__fortify_fail_abort): Don't pass down
__libc_argv[0] if we aren't doing backtrace. Rename do_backtrace
to need_backtrace.
* sysdeps/posix/libc_fatal.c (__libc_message): Don't call
__libc_secure_getenv if we aren't doing backtrace.
S390: fix sys/ptrace.h to make it includible again after asm/ptrace.h
sys/ptrace.h on S390 used to be includible both before and after
asm/ptrace.h, until commit b08a6a0dea63742313ed3d9577c1e2d83436b196
among other changes introduced PTRACE_SINGLEBLOCK enum constant which
is also defined in asm/ptrace.h as a macro, making sys/ptrace.h fail
to compile when included after asm/ptrace.h.
* sysdeps/unix/sysv/linux/s390/sys/ptrace.h [_LINUX_PTRACE_H ||
_S390_PTRACE_H]: Undefine all PTRACE_* macro constants defined
later as enum constants, except PTRACE_PEEKUSER, PTRACE_POKEUSER,
and PTRACE_SEIZE_DEVEL that are not defined by Linux headers.
After the recent update of int_select the comment needed an update, too.
While at this, all comments in LC_TELEPHONE were moved above their
respective values because this looks better. Some minor typos fixed.
[BZ #21783]
* localedata/locales/lg_UG (LC_TELEPHONE): Move all comments
above the values, correct some of them.
Add a hidden __stack_chk_fail_local alias to libc.so,
and make sure that on targets which use __stack_chk_fail,
this does not introduce a local PLT reference into libc.so.
defines __stack_chk_fail_local as an alias of __stack_chk_fail in libc.a.
There is no need to add stack_chk_fail_local.o to libc.a. We only need
to add stack_chk_fail_local.oS to libc_nonshared.a.
Tested on x86-64:
[hjl@gnu-skl-1 build-x86_64-linux]$ nm libc.a | grep __stack_chk_fail 0000000000000000 T __stack_chk_fail 0000000000000000 T __stack_chk_fail_local
[hjl@gnu-skl-1 build-x86_64-linux]$ nm libc_nonshared.a | grep __stack_chk_fail_local 0000000000000000 T __stack_chk_fail_local
[hjl@gnu-skl-1 build-x86_64-linux]$
Szabolcs Nagy [Mon, 17 Jul 2017 08:58:29 +0000 (09:58 +0100)]
[AArch64] Fix out of bound array access regression
Partially revert ea01a4da219011f4a4db97eef3c5bfc2f6e8fc6b
"aarch64: Add hwcap string routines" because _dl_procinfo cannot
be future proof and avoid oob access in _dl_hwcap_string.
The patch proposed by Peter Bergner [1] to libgcc in order to fix
[BZ #21707] adds a dependency on a symbol provided by the loader,
forcing the loader to be linked to tests after libgcc was linked.
It also requires to read the thread pointer during IRELA relocations.
Tested on powerpc, powerpc64, powerpc64le, s390x and x86_64.
projects / thirdparty / glibc.git / log
