about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* Add bits/floatn.h defines for more _FloatN / _FloatNx types.Joseph Myers2017-10-209-1/+316
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bits/floatn.h header currently only has defines relating to _Float128. This patch adds defines relating to other _FloatN / _FloatNx types. The approach taken is to add defines for all _FloatN / _FloatNx types known to GCC, and to put them in a common bits/floatn-common.h header included at the end of all the individual bits/floatn.h headers. If in future some defines become different for different glibc configurations, they will move out into the separate bits/floatn.h headers. Some defines are expected always to be the same across glibc ports. Corresponding defines are nevertheless put in this header. The intent is that where there are conditionals (in headers or in non-installed files) that can just repeat the same or nearly the same logic for each floating-point type, they should do so, even if in fact the cases for some types could be unconditionally present or absent because the same conditionals are true or false for all glibc configurations. This should make the glibc code with such conditionals easier to read, because the reader can just see that the same conditionals are repeated for each type, rather than seeing different conditionals for different types and needing to reason, at each location with such differences, why those differences are indeed correct there. (Cases involving per-format rather than per-type logic are more likely still to need differences in how they handle different types.) Having such defines and conditionals also helps in incremental preparation for adding _Float32 / _Float64 / _Float32x / _Float64x function aliases. I intend subsequent patches to add such conditionals corresponding to those already present for _Float128, as well as making more architecture-specific function implementations use common macros to define aliases in preparation for adding such _FloatN / _FloatNx aliases. Tested for x86_64. * bits/floatn-common.h: New file. * math/Makefile (headers): Add bits/floatn-common.h. * bits/floatn.h: Include <bits/floatn-common.h>. * sysdeps/ia64/bits/floatn.h: Likewise. * sysdeps/ieee754/ldbl-128/bits/floatn.h: Likewise. * sysdeps/mips/ieee754/bits/floatn.h: Likewise. * sysdeps/powerpc/bits/floatn.h: Likewise. * sysdeps/x86/bits/floatn.h: Likewise.
* Avoid build multiarch if compiler warns about mismatched aliasAdhemerval Zanella2017-10-203-6/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC 8 emits an warning for alias for functions with incompatible types and it is used extensivelly for ifunc resolvers implementations in C (for instance on weak_alias with the internal symbol name to the external one or with the libc_hidden_def to set ifunc for internal usage). This breaks the build when the ifunc resolver is not defined using gcc attribute extensions (HAVE_GCC_IFUNC being 0). Although for all currently architectures that have multiarch support this compiler options is enabled for default, there is still the option where the user might try build glibc with a compiler without support for such extension. In this case this patch just disable the multiarch folder in sysdeps selections. GCC 7 and before still builds IFUNCs regardless of compiler support (although for the lack of attribute support debug information would be optimal). Checked with a build on multiarch support architectures (aarch64, arm, sparc, s390, powerpc, x86_64, i386) with multiarch enable and disable and with GCC 7 and GCC 8. * configure.ac (libc_cv_gcc_incompatbile_alias): New define: indicates whether compiler emits an warning for alias for functions with incompatible types.
* posix: Fix improper assert in Linux posix_spawn (BZ#22273)Adhemerval Zanella2017-10-202-6/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As noted by Florian Weimer, current Linux posix_spawn implementation can trigger an assert if the auxiliary process is terminated before actually setting the err member: 340 /* Child must set args.err to something non-negative - we rely on 341 the parent and child sharing VM. */ 342 args.err = -1; [...] 362 new_pid = CLONE (__spawni_child, STACK (stack, stack_size), stack_size, 363 CLONE_VM | CLONE_VFORK | SIGCHLD, &args); 364 365 if (new_pid > 0) 366 { 367 ec = args.err; 368 assert (ec >= 0); Another possible issue is killing the child between setting the err and actually calling execve. In this case the process will not ran, but posix_spawn also will not report any error: 269 270 args->err = 0; 271 args->exec (args->file, args->argv, args->envp); As suggested by Andreas Schwab, this patch removes the faulty assert and also handles any signal that happens before fork and execve as the spawn was successful (and thus relaying the handling to the caller to figure this out). Different than Florian, I can not see why using atomics to set err would help here, essentially the code runs sequentially (due CLONE_VFORK) and I think it would not be legal the compiler evaluate ec without checking for new_pid result (thus there is no need to compiler barrier). Summarizing the possible scenarios on posix_spawn execution, we have: 1. For default case with a success execution, args.err will be 0, pid will not be collected and it will be reported to caller. 2. For default failure case, args.err will be positive and the it will be collected by the waitpid. An error will be reported to the caller. 3. For the unlikely case where the process was terminated and not collected by a caller signal handler, it will be reported as succeful execution and not be collected by posix_spawn (since args.err will be 0). The caller will need to actually handle this case. 4. For the unlikely case where the process was terminated and collected by caller we have 3 other possible scenarios: 4.1. The auxiliary process was terminated with args.err equal to 0: it will handled as 1. (so it does not matter if we hit the pid reuse race since we won't possible collect an unexpected process). 4.2. The auxiliary process was terminated after execve (due a failure in calling it) and before setting args.err to -1: it will also be handle as 1. but with the issue of not be able to report the caller a possible execve failures. 4.3. The auxiliary process was terminated after args.err is set to -1: this is the case where it will be possible to hit the pid reuse case where we will need to collected the auxiliary pid but we can not be sure if it will be expected one. I think for this case we need to actually change waitpid to use WNOHANG to avoid hanging indefinitely on the call and report an error to caller since we can't differentiate between a default failure as 2. and a possible pid reuse race issue. Checked on x86_64-linux-gnu. * sysdeps/unix/sysv/linux/spawni.c (__spawnix): Handle the case where the auxiliary process is terminated by a signal before calling _exit or execve.
* x86-64: Use fxsave/xsave/xsavec in _dl_runtime_resolve [BZ #21265]H.J. Lu2017-10-209-306/+296
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In _dl_runtime_resolve, use fxsave/xsave/xsavec to preserve all vector, mask and bound registers. It simplifies _dl_runtime_resolve and supports different calling conventions. ld.so code size is reduced by more than 1 KB. However, use fxsave/xsave/xsavec takes a little bit more cycles than saving and restoring vector and bound registers individually. Latency for _dl_runtime_resolve to lookup the function, foo, from one shared library plus libc.so: Before After Change Westmere (SSE)/fxsave 345 866 151% IvyBridge (AVX)/xsave 420 643 53% Haswell (AVX)/xsave 713 1252 75% Skylake (AVX+MPX)/xsavec 559 719 28% Skylake (AVX512+MPX)/xsavec 145 272 87% Ryzen (AVX)/xsavec 280 553 97% This is the worst case where portion of time spent for saving and restoring registers is bigger than majority of cases. With smaller _dl_runtime_resolve code size, overall performance impact is negligible. On IvyBridge, differences in build and test time of binutils with lazy binding GCC and binutils are noises. On Westmere, differences in bootstrap and "makc check" time of GCC 7 with lazy binding GCC and binutils are also noises. [BZ #21265] * sysdeps/x86/cpu-features-offsets.sym (XSAVE_STATE_SIZE_OFFSET): New. * sysdeps/x86/cpu-features.c: Include <libc-pointer-arith.h>. (get_common_indeces): Set xsave_state_size, xsave_state_full_size and bit_arch_XSAVEC_Usable if needed. (init_cpu_features): Remove bit_arch_Use_dl_runtime_resolve_slow and bit_arch_Use_dl_runtime_resolve_opt. * sysdeps/x86/cpu-features.h (bit_arch_Use_dl_runtime_resolve_opt): Removed. (bit_arch_Use_dl_runtime_resolve_slow): Likewise. (bit_arch_Prefer_No_AVX512): Updated. (bit_arch_MathVec_Prefer_No_AVX512): Likewise. (bit_arch_XSAVEC_Usable): New. (STATE_SAVE_OFFSET): Likewise. (STATE_SAVE_MASK): Likewise. [__ASSEMBLER__]: Include <cpu-features-offsets.h>. (cpu_features): Add xsave_state_size and xsave_state_full_size. (index_arch_Use_dl_runtime_resolve_opt): Removed. (index_arch_Use_dl_runtime_resolve_slow): Likewise. (index_arch_XSAVEC_Usable): New. * sysdeps/x86/cpu-tunables.c (TUNABLE_CALLBACK (set_hwcaps)): Support XSAVEC_Usable. Remove Use_dl_runtime_resolve_slow. * sysdeps/x86_64/Makefile (tst-x86_64-1-ENV): New if tunables is enabled. * sysdeps/x86_64/dl-machine.h (elf_machine_runtime_setup): Replace _dl_runtime_resolve_sse, _dl_runtime_resolve_avx, _dl_runtime_resolve_avx_slow, _dl_runtime_resolve_avx_opt, _dl_runtime_resolve_avx512 and _dl_runtime_resolve_avx512_opt with _dl_runtime_resolve_fxsave, _dl_runtime_resolve_xsave and _dl_runtime_resolve_xsavec. * sysdeps/x86_64/dl-trampoline.S (DL_RUNTIME_UNALIGNED_VEC_SIZE): Removed. (DL_RUNTIME_RESOLVE_REALIGN_STACK): Check STATE_SAVE_ALIGNMENT instead of VEC_SIZE. (REGISTER_SAVE_BND0): Removed. (REGISTER_SAVE_BND1): Likewise. (REGISTER_SAVE_BND3): Likewise. (REGISTER_SAVE_RAX): Always defined to 0. (VMOV): Removed. (_dl_runtime_resolve_avx): Likewise. (_dl_runtime_resolve_avx_slow): Likewise. (_dl_runtime_resolve_avx_opt): Likewise. (_dl_runtime_resolve_avx512): Likewise. (_dl_runtime_resolve_avx512_opt): Likewise. (_dl_runtime_resolve_sse): Likewise. (_dl_runtime_resolve_sse_vex): Likewise. (USE_FXSAVE): New. (_dl_runtime_resolve_fxsave): Likewise. (USE_XSAVE): Likewise. (_dl_runtime_resolve_xsave): Likewise. (USE_XSAVEC): Likewise. (_dl_runtime_resolve_xsavec): Likewise. * sysdeps/x86_64/dl-trampoline.h (_dl_runtime_resolve_avx512): Removed. (_dl_runtime_resolve_avx512_opt): Likewise. (_dl_runtime_resolve_avx): Likewise. (_dl_runtime_resolve_avx_opt): Likewise. (_dl_runtime_resolve_sse): Likewise. (_dl_runtime_resolve_sse_vex): Likewise. (_dl_runtime_resolve_fxsave): New. (_dl_runtime_resolve_xsave): Likewise. (_dl_runtime_resolve_xsavec): Likewise.
* Mention Tim Rühsen as the reporter for CVE-2017-15670Florian Weimer2017-10-201-3/+4
|
* CVE-2017-15670: glob: Fix one-byte overflow [BZ #22320]Paul Eggert2017-10-203-1/+11
|
* Fix build issue with SINGLE_THREAD_PWilco Dijkstra2017-10-202-0/+7
| | | | | | Add sysdep-cancel.h include. * malloc/malloc.c (sysdep-cancel.h): Add include.
* Add single-threaded path to _int_freeWilco Dijkstra2017-10-202-14/+33
| | | | | | | This patch adds single-threaded fast paths to _int_free. Bypass the explicit locking for larger allocations. * malloc/malloc.c (_int_free): Add SINGLE_THREAD_P fast paths.
* resolv: Remove bogus targets that build ga_testWill Hawkins2017-10-203-105/+6
| | | | | | | | | | | | | | | | | | Remove the bogus targets (and source) that supposedly build ga_test. This code was added to resolv very early in the development process but does not appear to be an actual test program. The target for building this file is tests but because the glibc Make system is built the way it is, the target is overriden by higher-level tests targets and, therefore, the ga_test program is never built. Removing the target and the source code makes the resolv/Makefile less confusing. Tested by building and running 'make check' on 64 bit host running Kernel 4.10.0-19 configured with --prefix=/home/hawkinsw/code/glibc-build/install --enable-hardcoded-path-in-tests --disable-mathvec Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Add new locale kab_DZ [BZ #18812]Mike FABIAN2017-10-203-0/+175
| | | | | | [BZ #18812] * localedata/SUPPORTED: Add kab_DZ/UTF-8. * localedata/locales/kab_DZ: New file.
* m68k: Update elf_machine_load_address for static PIEH.J. Lu2017-10-202-0/+12
| | | | | | | | | When --enable-static-pie is used to configure glibc, we need to use _dl_relocate_static_pie to compute load address in static PIE. * sysdeps/m68k/dl-machine.h (elf_machine_load_address): Use _dl_relocate_static_pie instead of _dl_start to compute load address in static PIE.
* m68k: Check PIC instead of SHARED in start.SH.J. Lu2017-10-202-1/+5
| | | | | | | Since start.o may be compiled as PIC, we should check PIC instead of SHARED. * sysdeps/m68k/start.S (_start): Check PIC instead of SHARED.
* Add new locale shn_MM [BZ #13605]Mike FABIAN2017-10-203-0/+299
| | | | | | [BZ #13605] * localedata/SUPPORTED: Add shn_MM/UTF-8. * localedata/locales/shn_MM: New file.
* sysconf: Fix missing definition of UIO_MAXIOV on Linux [BZ #22321]Florian Weimer2017-10-205-1/+82
| | | | | | | After commit 37f802f86400684c8d13403958b2c598721d6360 (Remove __need_IOV_MAX and __need_FOPEN_MAX), UIO_MAXIOV is no longer supplied (indirectly) through <bits/stdio_lim.h>, so sysdeps/posix/sysconf.c no longer sees the definition.
* i386: Regenerate libm-test-ulpsH.J. Lu2017-10-192-2/+6
| | | | | | Regenerate libm-test-ulps for --disable-multi-arch. * sysdeps/i386/fpu/libm-test-ulps: Regenerated.
* Add MIPS bits/floatn.h.Joseph Myers2017-10-192-0/+82
| | | | | | | | | | | | | | This patch adds a MIPS-specific bits/floatn.h header. This header is identical to the ldbl-128 version except for the comment at the top; the purpose is to ensure that a 32-bit MIPS build installs a header that is the same as in a 64-bit MIPS build and so properly shows _Float128 support to be available for 64-bit compilations, on the general principle of an installation for one multilib providing headers also suitable for other multilibs. Tested with build-many-glibcs.py. * sysdeps/mips/ieee754/bits/floatn.h: New file.
* Install correct bits/long-double.h for MIPS64 (bug 22322).Joseph Myers2017-10-192-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | Similar to bug 21987 for SPARC, MIPS64 wrongly installs the ldbl-128 version of bits/long-double.h, meaning incorrect results when using headers installed from a 64-bit installation for a 32-bit build. (I haven't actually seen this cause build failures before its interaction with bits/floatn.h did so - installed headers wrongly expecting _Float128 to be available in a 32-bit configuration.) This patch fixes the bug by moving the MIPS header to sysdeps/mips/ieee754, which comes before sysdeps/ieee754/ldbl-128 in the sysdeps directory ordering. (bits/floatn.h will need a similar fix - duplicating the ldbl-128 version for MIPS will suffice - for headers from a 32-bit installation to be correct for 64-bit builds.) Tested with build-many-glibcs.py (compilers build for mips64-linux-gnu, where there was previously a libstdc++ build failure as at <https://sourceware.org/ml/libc-testresults/2017-q4/msg00130.html>). [BZ #22322] * sysdeps/mips/bits/long-double.h: Move to .... * sysdeps/mips/ieee754/bits/long-double.h: ... here.
* Fix deadlock in _int_free consistency checkWilco Dijkstra2017-10-192-9/+16
| | | | | | | | | | This patch fixes a deadlock in the fastbin consistency check. If we fail the fast check due to concurrent modifications to the next chunk or system_mem, we should not lock if we already have the arena lock. Simplify the check to make it obviously correct. * malloc/malloc.c (_int_free): Fix deadlock bug in consistency check.
* x86-64: Don't set GLRO(dl_platform) to NULL [BZ #22299]H.J. Lu2017-10-196-4/+124
| | | | | | | | | | | | | | | | | | | | | | | Since ld.so expands $PLATFORM with GLRO(dl_platform), don't set GLRO(dl_platform) to NULL. [BZ #22299] * sysdeps/x86/cpu-features.c (init_cpu_features): Don't set GLRO(dl_platform) to NULL. * sysdeps/x86_64/Makefile (tests): Add tst-platform-1. (modules-names): Add tst-platformmod-1 and x86_64/tst-platformmod-2. (CFLAGS-tst-platform-1.c): New. (CFLAGS-tst-platformmod-1.c): Likewise. (CFLAGS-tst-platformmod-2.c): Likewise. (LDFLAGS-tst-platformmod-2.so): Likewise. ($(objpfx)tst-platform-1): Likewise. ($(objpfx)tst-platform-1.out): Likewise. (tst-platform-1-ENV): Likewise. ($(objpfx)x86_64/tst-platformmod-2.os): Likewise. * sysdeps/x86_64/tst-platform-1.c: New file. * sysdeps/x86_64/tst-platformmod-1.c: Likewise. * sysdeps/x86_64/tst-platformmod-2.c: Likewise.
* Add new locale mjw_IN [BZ #13994]Mike FABIAN2017-10-194-0/+165
| | | | | | | [BZ #13994] * locale/iso-639.def: Add Karbi. * localedata/SUPPORTED: Add mjw_IN/UTF-8. * localedata/locales/mjw_IN: New file.
* Add _Float128 function aliases.Joseph Myers2017-10-1823-3/+906
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for *f128 function aliases on platforms where long double has the binary128 format (and thus GCC 7 provides the _Float128 type with the same ABI as long double but as a distinct type in terms of C type compatibility). This is the same API as provided in glibc 2.26 for powerpc64le / x86_64 / x86 / ia64 where _Float128 has a different format from long double, with the bulk of the API coming from TS 18661-3. All the functions alias the corresponding long double functions, and __* function names are not provided since those are only needed once for each floating-point format, not more than once for different types with the same format (so for example, -ffinite-math-only maps foof128 to __fool_finite, while type-generic macros end up calling e.g. __issignalingl for _Float128 arguments on such platforms). The preparation for this feature was done in previous patches, so this one just needs to add the relevant makefile and header definitions, and update macro definitions of libm_alias_ldouble_other_r, to turn on the feature, and update documentation and ABI baselines. Tested (a) for x86_64, (b) for aarch64, (c) with build-many-glibcs.py with both GCC 6 and GCC 7. * sysdeps/ieee754/ldbl-128/Makeconfig: New file. * sysdeps/ieee754/ldbl-128/bits/floatn.h: Likewise. * sysdeps/ieee754/ldbl-128/float128-abi.h: Likewise. * sysdeps/generic/libm-alias-ldouble.h: Include <bits/floatn.h>. [__HAVE_FLOAT128 && !__HAVE_DISTINCT_FLOAT128] (libm_alias_ldouble_other_r): Also create _Float128 alias. * sysdeps/ieee754/ldbl-opt/libm-alias-ldouble.h: Include <bits/floatn.h>. [__HAVE_FLOAT128 && !__HAVE_DISTINCT_FLOAT128] (libm_alias_ldouble_other_r): Also create _Float128 alias. * manual/math.texi (Mathematics): Document additional architecture support for _Float128. * sysdeps/unix/sysv/linux/aarch64/libc.abilist: Update. * sysdeps/unix/sysv/linux/aarch64/libm.abilist: Likewise. * sysdeps/unix/sysv/linux/alpha/libc.abilist: Likewise. * sysdeps/unix/sysv/linux/alpha/libm.abilist: Likewise. * sysdeps/unix/sysv/linux/mips/mips64/libm.abilist: Likewise. * sysdeps/unix/sysv/linux/mips/mips64/n32/libc.abilist: Likewise. * sysdeps/unix/sysv/linux/mips/mips64/n64/libc.abilist: Likewise. * sysdeps/unix/sysv/linux/s390/s390-32/libc.abilist: Likewise. * sysdeps/unix/sysv/linux/s390/s390-32/libm.abilist: Likewise. * sysdeps/unix/sysv/linux/s390/s390-64/libc.abilist: Likewise. * sysdeps/unix/sysv/linux/s390/s390-64/libm.abilist: Likewise. * sysdeps/unix/sysv/linux/sparc/sparc32/libc.abilist: Likewise. * sysdeps/unix/sysv/linux/sparc/sparc32/libm.abilist: Likewise. * sysdeps/unix/sysv/linux/sparc/sparc64/libc.abilist: Likewise. * sysdeps/unix/sysv/linux/sparc/sparc64/libm.abilist: Likewise.
* [AARCH64] Rewrite elf_machine_load_address using _DYNAMIC symbolSzabolcs Nagy2017-10-182-34/+10
| | | | | | | | | | | | | | | | | | | | This patch rewrites aarch64 elf_machine_load_address to use special _DYNAMIC symbol instead of _dl_start. The static address of _DYNAMIC symbol is stored in the first GOT entry. Here is the change which makes this solution work (part of binutils 2.24): https://sourceware.org/ml/binutils/2013-06/msg00248.html i386, x86_64 targets use the same method to do this as well. The original implementation relies on a trick that R_AARCH64_ABS32 relocation being resolved at link time and the static address fits in the 32bits. However, in LP64, normally, the address is defined to be 64 bit. Here is the C version one which should be portable in all cases. * sysdeps/aarch64/dl-machine.h (elf_machine_load_address): Use _DYNAMIC symbol to calculate load address.
* powerpc: fix check-before-set in SET_RESTORE_ROUNDPaul Clarke2017-10-182-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A performance regression was introduced by commit 84d74e427a771906830800e574a72f8d25a954b8 "powerpc: Cleanup fenv_private.h". In the powerpc implementation of SET_RESTORE_ROUND, there is the following code in the "SET" function (slightly simplified): -- old.fenv = fegetenv_register (); new.l = (old.l & _FPU_MASK_TRAPS_RN) | r; (1) if (new.l != old.l) (2) { if ((old.l & _FPU_ALL_TRAPS) != 0) (void) __fe_mask_env (); fesetenv_register (new.fenv); (3) -- Line (1) sets the value of "new" to the current value of FPSCR, but masks off summary bits, exceptions, non-IEEE mode, and rounding mode, then ORs in the new rounding mode. Line (2) compares this new value to the current value in order to avoid setting a new value in the FPSCR (line (3)) unless something significant has changed (exception enables or rounding mode). The summary bits are not germane to the comparison, but are cleared in "new" and preserved in "old", resulting in false negative comparisons, and unnecessarily setting the FPSCR in those cases with associated negative performance impacts. The solution is to treat the summaries identically for "new" and "old": - save them in SET - leave them alone otherwise - restore the saved values in RESTORE Also minor changes: - expand _FPU_MASK_RN to 64bit hex, to match other MASKs - treat bit 52 (left-to-right) as reserved (since it is) * sysdeps/powerpc/fpu/fenv_private.h (_FPU_MASK_TRAPS_RN): (_FPU_MASK_FRAC_INEX_RET_CC): Fix masks to more properly handle summary bits. (_FPU_MASK_RN): Expand _FPU_MASK_RN to 64bit hex. (_FPU_MASK_NOT_RN_NI): Treat bit 52 (left-to-right) as reserved. Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
* Use U+202F NARROW NO-BREAK SPACE as thousands separators in pl_PL locale [BZ ↵Mike FABIAN2017-10-182-8/+16
| | | | | | | | | | #16777] [BZ #16777] * localedata/locales/pl_PL (LC_MONETARY): Use U+202F as mon_thousands_sep and improve readability by using more ASCII. * localedata/locales/pl_PL (LC_NUMERIC): Use U+202F as thousands_sep and improve readability by using more ASCII.
* Fix build failure on tilepro due to unsupported atomicsWilco Dijkstra2017-10-182-1/+7
| | | | | * malloc/malloc.c (malloc_state): Use int for have_fastchunks since not all targets support atomics on bool.
* Use __f128 to define FLT128_* constants in include/float.h for old GCC.Joseph Myers2017-10-172-4/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | When using compilers before GCC 7, include/float.h provides fallback definitions of FLT128_* constants. These definitions use 'Q' constant suffixes, which works for configurations with _Float128 ABI-distinct from long double, but not where it has the same ABI as long double. This patch changes the definitions to use the __f128 macro from <bits/floatn.h>, so allowing them to work in the non-distinct _Float128 case (where they are used in building glibc tests, not for building glibc itself) as well. Tested (a) with build-many-glibcs.py with GCC 6 (installed stripped shared libraries unchanged by the patch); (b) with build-many-glibcs.py with GCC 6 together with the main patch to enable float128 aliases; (c) for x86_64 with both GCC 6 and GCC 7. * include/float.h [!__GNUC_PREREQ (7, 0) && __HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (FLT128_MAX): Define using __f128. [!__GNUC_PREREQ (7, 0) && __HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (FLT128_EPSILON): Likewise. [!__GNUC_PREREQ (7, 0) && __HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (FLT128_MIN): Likewise. [!__GNUC_PREREQ (7, 0) && __HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (FLT128_TRUE_MIN): Likewise.
* posix: Add p{readv,writev}2 flags to generic uio-ext.hAdhemerval Zanella2017-10-173-3/+11
| | | | | * bits/uio-ext.h (RWF_HIPRI, RWF_DSYNC, RWF_SYNC, RWF_NOWAIT): New defines.
* Improve malloc initialization sequenceWilco Dijkstra2017-10-173-118/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | The current malloc initialization is quite convoluted. Instead of sometimes calling malloc_consolidate from ptmalloc_init, call malloc_init_state early so that the main_arena is always initialized. The special initialization can now be removed from malloc_consolidate. This also fixes BZ #22159. Check all calls to malloc_consolidate and remove calls that are redundant initialization after ptmalloc_init, like in int_mallinfo and __libc_mallopt (but keep the latter as consolidation is required for set_max_fast). Update comments to improve clarity. Remove impossible initialization check from _int_malloc, fix assert in do_check_malloc_state to ensure arena->top != 0. Fix the obvious bugs in do_check_free_chunk and do_check_remalloced_chunk to enable single threaded malloc debugging (do_check_malloc_state is not thread safe!). [BZ #22159] * malloc/arena.c (ptmalloc_init): Call malloc_init_state. * malloc/malloc.c (do_check_free_chunk): Fix build bug. (do_check_remalloced_chunk): Fix build bug. (do_check_malloc_state): Add assert that checks arena->top. (malloc_consolidate): Remove initialization. (int_mallinfo): Remove call to malloc_consolidate. (__libc_mallopt): Clarify why malloc_consolidate is needed.
* Use relaxed atomics for malloc have_fastchunksWilco Dijkstra2017-10-172-32/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently free typically uses 2 atomic operations per call. The have_fastchunks flag indicates whether there are recently freed blocks in the fastbins. This is purely an optimization to avoid calling malloc_consolidate too often and avoiding the overhead of walking all fast bins even if all are empty during a sequence of allocations. However using catomic_or to update the flag is completely unnecessary since it can be changed into a simple boolean and accessed using relaxed atomics. There is no change in multi-threaded behaviour given the flag is already approximate (it may be set when there are no blocks in any fast bins, or it may be clear when there are free blocks that could be consolidated). Performance of malloc/free improves by 27% on a simple benchmark on AArch64 (both single and multithreaded). The number of load/store exclusive instructions is reduced by 33%. Bench-malloc-thread speeds up by ~3% in all cases. * malloc/malloc.c (FASTCHUNKS_BIT): Remove. (have_fastchunks): Remove. (clear_fastchunks): Remove. (set_fastchunks): Remove. (malloc_state): Add have_fastchunks. (malloc_init_state): Use have_fastchunks. (do_check_malloc_state): Remove incorrect invariant checks. (_int_malloc): Use have_fastchunks. (_int_free): Likewise. (malloc_consolidate): Likewise.
* Inline tcache functionsWilco Dijkstra2017-10-172-2/+7
| | | | | | | | | | | The functions tcache_get and tcache_put show up in profiles as they are a critical part of the tcache code. Inline them to give tcache a 16% performance gain. Since this improves multi-threaded cases as well, it helps offset any potential performance loss due to adding single-threaded fast paths. * malloc/malloc.c (tcache_put): Inline. (tcache_get): Inline.
* Fix armv7-a compiler option nameAdhemerval Zanella2017-10-171-2/+2
| | | | | This patch fixes the wrong -march name option used to define the ARMv7-A glibc variant pushed on commit 3d26560.
* New locale ca_ES@valencia [BZ #2522]Aurelien Jarno2017-10-173-0/+95
| | | | | | | | | | | | | The Valencian (meridional Catalan) locale is basically a copy of the Catalan locale. The point of having a separate locale is only for PO translations. This locale is already provided by several distributions and is already supported by various projects like LibreOffice, Mozilla, Gnome, KDE. Aurelien Jarno <aurelien@aurel32.net> [BZ #2522] * localedata/locales/ca_ES@valencia: New file. * localedata/SUPPORTED: Add ca_ES@valencia/UTF-8.
* Let signbit use the builtin in C++ mode with gcc < 6.x (bug 22296)Romain Naour2017-10-172-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using gcc < 6.x, signbit does not use the type-generic __builtin_signbit builtin, instead it uses __MATH_TG. However, when library support for float128 is available, __MATH_TG uses __builtin_types_compatible_p, which is not available in C++ mode. On the other hand, libstdc++ undefines (in cmath) many macros from math.h, including signbit, so that it can provide its own functions. However, during its configure tests, libstdc++ just tests for the availability of the macros (it does not undefine them, nor does it provide its own functions). Finally, libstdc++ configure tests include math.h and get the definition of signbit that uses __MATH_TG (and __builtin_types_compatible_p). Since libstdc++ does not undefine the macros during its configure tests, they fail. This patch lets signbit use the builtin in C++ mode when gcc < 6.x is used. This allows the configure test in libstdc++ to work. Tested for x86_64. [BZ #22296] * math/math.h: Let signbit use the builtin in C++ mode with gcc < 6.x Cc: Gabriel F. T. Gomes <gftg@linux.vnet.ibm.com> Cc: Joseph Myers <joseph@codesourcery.com>
* Add build-many-glibcs.py arm-linux-gnueabihf-v7{-disable-multiarch}Adhemerval Zanella2017-10-172-1/+9
| | | | | | | | | | | | | | | This patch adds two extra configuration for arm-linux-gnueabihf to cover for multiarch support: 1. arm-linux-gnueabihf-v7a: enables multiarch support by using -march=armv7a. 2. Same as 1. but with --disable-multiarch. Check with build-many-glibcs.py for both options. * scripts/build-many-glibcs.py (Context.add_all_configs): Add arm-linux-gnueabihf multiarch extra_glibcs.
* Add common ifunc-init.h headerAdhemerval Zanella2017-10-173-40/+60
| | | | | | | | | | This patch moves the generic definition from x86_64 init-arch to a common header ifunc-init.h. No functional changes is expected. Checked on a x86_64-linux-gnu build. * sysdeps/generic/ifunc-init.h: New file. * sysdeps/x86/init-arch.h: Use generic ifunc-init.h.
* Place monetary symbol in el_GR and el_CY after the amountMike FABIAN2017-10-174-18/+11
| | | | | | | | | CLDR uses this pattern as well. [BZ #22019] * localedata/locales/el_GR: Set n_cs_precedes to 0. * localedata/locales/el_CY: copy "el_GR" because it is identical. * stdlib/tst-strfmon_l.c: adapt test case.
* Move some float128 symbol version definitions.Joseph Myers2017-10-165-109/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With support for _Float128 functions on platforms where that type has the same ABI as long double, as well as on platforms where it is ABI-distinct, those functions will need to be exported from glibc's shared libraries at appropriate symbol versions in each case. This patch avoids duplication of lists of symbols to export by moving the symbols other than __* to math/Versions and stdlib/Versions. There, they are conditional on <float128-abi.h> defining FLOAT128_VERSION and a default version of that header is added that does not define that macro. Enabling the float128 function aliases will then include adding a sysdeps/ieee754/ldbl-128/float128-abi.h that defines FLOAT128_VERSION to GLIBC_2.27. Symbols __* remain in sysdeps/ieee754/float128/Versions; those symbols should be present only once per floating-point format, not once per type. Note that if any platforms currently lacking support for a type with binary128 format get glibc support for such a type in future (whether only as _Float128, or also as a new long double format), and new libm functions (present for all types) have been added by then, additional macros will be needed to allow such functions to get a version of the form "GLIBC_2.28 if the platform had _Float128 support by then, or the later version at which that platform had _Float128 support added". This is not however a preexisting condition, but would have applied equally to the existing support for _Float128 as an ABI-distinct type. New all-type libm functions should just be added to the appropriate symbol version (currently GLIBC_2.27) for all types, with such special-case handling for _Float128 versions (and _Float64x as well in future) waiting until someone actually wants to add support for _Float128 to an existing platform after a release in which that platform and a post-2.26 libm function had support but that platform lacked _Float128 support. Tested with build-many-glibcs.py that installed stripped shared libraries are unchanged by this patch. Also tested in conjunction with the remaining changes to enable float128 aliases. * sysdeps/generic/float128-abi.h: New file. * sysdeps/ieee754/float128/Versions (FLOAT128_VERSION): Move non-__prefixed symbols to .... * math/Versions: ... here. Include <float128-abi.h>. * stdlib/Versions ... and here. Include <float128-abi.h>
* version.h: Switch to ".9000" as the suffix for the development versionFlorian Weimer2017-10-162-1/+6
|
* malloc: Use compat_symbol_reference in libmcheck [BZ #22050]Florian Weimer2017-10-162-0/+9
| | | | | | | | Since glibc 2.24, __malloc_initialize_hook is a compat symbol. As a result, the link editor does not export a definition of __malloc_initialize_hook from the main program, so that it no longer interposes the variable definition in libc.so. Specifying the symbol version restores the exported symbol.
* malloc: Do not compile mcheck-init.o as libc moduleFlorian Weimer2017-10-162-0/+5
| | | | | Otherwise, this will lead to a link failure because the reference to mcheck is hidden.
* shlib-compat: Update documentation of the compat_symbol_reference macroCarlos O'Donell2017-10-162-2/+11
|
* Support running libm tests for float128 as alias for long double.Joseph Myers2017-10-163-4/+18
| | | | | | | | | | | | | | | | | | | This patch adds support for running libm tests for float128 in the case where the float128 functions are aliases of long double functions. In this case, the sysdeps Makeconfig file (i.e. sysdeps/ieee754/ldbl-128/Makeconfig) will need to define "float128-alias-fcts = yes" to enable the tests. Tested for x86_64. Also tested with build-many-glibcs.py; installed stripped shared libraries are unchanged by the patch. Also tested together with changes to enable the float128 aliases. * math/Makefile (test-types): Add $(type-float128-$(float128-alias-fcts)). * math/test-float128.h (TYPE_STR): Define conditional on [FLT128_MANT_DIG == LDBL_MANT_DIG]. (ULP_IDX): Likewise. (ULP_I_IDX): Likewise.
* Support strtof128 etc. aliases.Joseph Myers2017-10-164-0/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for building strtof128, wcstof128, strtof128_l and wcstof128_l as aliases, in the case of __HAVE_FLOAT128 && !__HAVE_DISTINCT_FLOAT128. Tested with build-many-glibcs.py that installed stripped shared libraries are unchanged by this patch. Also tested together with changes to enable float128 aliases. * stdlib/strtold.c: Include <bits/floatn.h> [__HAVE_FLOAT128 && !__HAVE_DISTINCT_FLOAT128] (strtof128): Define and later undefine as macro. Define as weak alias if [!USE_WIDE_CHAR]. [__HAVE_FLOAT128 && !__HAVE_DISTINCT_FLOAT128] (wcstof128): Define and later undefine as macro. Define as weak alias if [USE_WIDE_CHAR]. * sysdeps/ieee754/ldbl-128/strtold_l.c [__HAVE_FLOAT128 && !__HAVE_DISTINCT_FLOAT128] (strtof128_l): Define and later undefine as macro. Define as weak alias if [!USE_WIDE_CHAR]. [__HAVE_FLOAT128 && !__HAVE_DISTINCT_FLOAT128] (wcstof128_l): Define and later undefine as macro. Define as weak alias if [USE_WIDE_CHAR]. * sysdeps/ieee754/ldbl-64-128/strtold_l.c: Include <bits/floatn.h>. [__HAVE_FLOAT128 && !__HAVE_DISTINCT_FLOAT128] (strtof128_l): Define and later undefine as macro. Define as weak alias if [!USE_WIDE_CHAR]. [__HAVE_FLOAT128 && !__HAVE_DISTINCT_FLOAT128] (wcstof128_l): Define and later undefine as macro. Define as weak alias if [USE_WIDE_CHAR].
* locale: Don't use \n with record_verbose messages.Carlos O'Donell2017-10-152-3/+8
| | | | | | | | | Recorded verbose messages no longer need to pass \n in their message string since the record_verbose function adds \n to the messages (like error and warnings do also). The avoids seeing a double \n for verbose messages. Signed-off-by: Carlos O'Donell <carlos@redhat.com>
* Silence -O3 -Wall warning in malloc/hooks.c with GCC 7 [BZ #22052]H.J. Lu2017-10-152-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | realloc_check has unsigned char *magic_p; ... __libc_lock_lock (main_arena.mutex); const mchunkptr oldp = mem2chunk_check (oldmem, &magic_p); __libc_lock_unlock (main_arena.mutex); if (!oldp) malloc_printerr ("realloc(): invalid pointer"); ... if (newmem == NULL) *magic_p ^= 0xFF; with static void malloc_printerr(const char *str) __attribute__ ((noreturn)); GCC 7 -O3 warns hooks.c: In function ‘realloc_check’: hooks.c:352:14: error: ‘magic_p’ may be used uninitialized in this function [-Werror=maybe-uninitialized] *magic_p ^= 0xFF; due to the GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090 This patch silences GCC 7 by using DIAG_IGNORE_NEEDS_COMMENT. [BZ #22052] * malloc/hooks.c (realloc_check): Use DIAG_IGNORE_NEEDS_COMMENT to silence -O3 -Wall warning with GCC 7.
* Add a test for profiling static executableH.J. Lu2017-10-145-1/+102
| | | | | | | | | | | | | | | | | | | | The function, main, is added to profiling output of static executable which must link against gcrt1.o. * Makeconfig (+link-static-before-libc): Use the first of $(CRT-$(@F)) and $(csu-objpfx)$(static-start-installed-name). * gmon/Makefile (tests): Add tst-gmon-static. (tests-static): Likewise. (CFLAGS-tst-gmon-static.c): New. (CRT-tst-gmon-static): Likewise. (DEFAULT-LDFLAGS-tst-gmon-static): Likewise. (tst-gmon-static-ENV): Likewise. (tests-special): Likewise. ($(objpfx)tst-gmon-static.out): Likewise. (clean-tst-gmon-static-data): Likewise. ($(objpfx)tst-gmon-static-gprof.out): Likewise. * gmon/tst-gmon-static-gprof.sh: New file. * gmon/tst-gmon-static.c: Likewise.
* locale: No warning for non-symbolic character (bug 22295)Carlos O'Donell2017-10-132-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | In "Is it OK to write ASCII strings directly into locale source files?" https://sourceware.org/ml/libc-alpha/2017-07/msg00807.html there is universal consensus that we do not have to keep writing <Uxxxx> symbolic characters in locale files. Ulrich Drepper's historical comment was that symbolic characters were used for the eventuality of converting the source files to any encoding system. Fast forward to today and UTF-8 is the standard. So the requirement of <Uxxxx> is hard to justify. Zack Weinberg's excellent scripts are coming along we can use these to find instances of human errors in the scripts: https://sourceware.org/ml/libc-alpha/2017-07/msg00860.html https://sourceware.org/ml/libc-alpha/2017-08/msg00136.html It still won't be easy to distinguish from i for í, but that's still the case for <Uxxxx> characters which humans can't read either. Since we all agreed that we should be able to use non-symbolic (<Uxxxx>) characters in locale files, the following change removes the verbose warning that is raised if you use non-symbolic characters in the locale file. Signed-off-by: Carlos O'Donell <carlos@redhat.com>
* locale: Allow "" int_curr_Symbol (bug 22294)Carlos O'Donell2017-10-132-2/+14
| | | | | | | | | | | | | | | The builtin POSIX locale has "" as the international currency symbol, but a non-builtin locale may not have such a blank int_curr_symbol. Therefore to support non-builtin locales with similar "" int_curr_symbol we adjust the LC_MONETARY parser to allow the normal 4-character int_curr_symbol *and* the empty "" no symbol. Anything else remains invalid. Tested by building all the locales. Tested also with a custom C.UTF-8 locale with "" for int_curr_symbol. Signed-off-by: Carlos O'Donell <carlos@redhat.com>
* locale: Fix localedef exit code (Bug 22292)Carlos O'Donell2017-10-1326-489/+767
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The error and warning handling in localedef, locale, and iconv is a bit of a mess. We use ugly constructs like this: WITH_CUR_LOCALE (error (1, errno, gettext ("\ cannot read character map directory `%s'"), directory)); to issue errors, and read error_message_count directly from the error API to detect errors. The problem with that is that the code also uses error to print warnings, and informative messages. All of this leads to problems where just having warnings will produce an exit status as-if errors had been seen. To fix this situation I have adopted the following high-level changes: * All errors are counted distinctly. * All warnings are counted distinctly. * All informative messages are not counted. * Increasing verbosity cannot generate *more* errors, and it previously did for errors conditional on verbose, this is now fixed. * Increasing verbosity *can* generate *more* warnings. * Making the output quiet cannot generate *fewer* errors, and it previously did for errors conditional on be_quiet, this is now fixed. * Each of error, warning, and informative message has it's own function to call defined in record-status.h, and they are: record_error, record_warning, and record_verbose. * The record_error function always records an error, but conditional on be_quiet may not print it. * The record_warning function always records a warning, but conditional on be_quiet may not print it. * The record_verbose function only prints the verbose message if verbose is true and be_quiet is false. This has allowed the following fix: * Previously any warnings were being treated as errors because they incremented error_message_count, but now we properly return an exit status of 1 if there are warnings but output was generated. All of this allows localedef to correctly decide if errors, or warnings were present, and produce the correct exit code. The locale and iconv programs now also use record-status.h and we have removed the WITH_CUR_LOCALE hack, and instead have internal push_locale/pop_locale functions centralized in the record routines. Signed-off-by: Carlos O'Donell <carlos@redhat.com>
* localedata: Reorganize Unicode LC_CTYPE inclusion.Carlos O'Donell2017-10-134-2309/+2369
| | | | | | | | | | | | | | | | The commit does the following things: * Move non-transliteration Unicode generated data to i18n_ctype. * Copy the i18n_ctype data into i18n and add transliteration. In the future, any locale which needs Unicode LC_CTYPE data can also just use `copy i18n_ctype` and get the base character classes and maps without transliteration. Tested by compiling all the locales and my prototype C.UTF-8 which uses it. Signed-off-by: Carlos O'Donell <carlos@redhat.com>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-22 14:19:23 +0000