Mike FABIAN [Fri, 27 Oct 2017 08:53:35 +0000 (10:53 +0200)]
Fix all remaining issues of [BZ #15260]
[BZ #15260]
* localedata/locales/doi_IN (LC_MESSAGES): Match only for the
first letters of yesstr and nostr in yesexpr and noexpr,
not for the full words.
* localedata/locales/hne_IN (LC_MESSAGES): Likewise.
* localedata/locales/kok_IN (LC_MESSAGES): Likewise.
* localedata/locales/mr_IN (LC_MESSAGES): Likewise.
* localedata/locales/sat_IN (LC_MESSAGES): Likewise.
* localedata/locales/km_KH (LC_MESSAGES): Match also for the
first letters of yesstr and nostr in yesexpr and noexpr,
until now only English was matched in yesexpr and noexpr.
* localedata/locales/tl_PH (LC_MESSAGES): Use “copy "fil_PH"”
instead of “copy "en_US"”. CLDR has yesstr and nostr data for
fil but not for tl. As tl and fil are very similar, using fil
is probably better than using English.
Joseph Myers [Thu, 26 Oct 2017 23:34:55 +0000 (23:34 +0000)]
Add SNAN macros for more _FloatN, _FloatNx types.
This patch continues the preparation for additional _FloatN / _FloatNx
type support by adding appropriately conditional definitions of SNAN*
macros, corresponding to the SNANF128 definition already present.
Joseph Myers [Thu, 26 Oct 2017 23:11:18 +0000 (23:11 +0000)]
Add HUGE_VAL macros for more _FloatN, _FloatNx types.
This patch continues the preparation for additional _FloatN / _FloatNx
type support by adding appropriately conditional definitions of
HUGE_VAL_* macros, corresponding to the HUGE_VAL_F128 definition
already present.
Thierry Vignaud [Wed, 25 Oct 2017 20:12:31 +0000 (22:12 +0200)]
fix nostr for "br" [BZ #21706]
"Ket" is the the most used negative answer, as it's the negative answer
to a positively phrased question
It's used as it or with the verb ("Ne ran ket", ...)
As such, "Ket" is used in most translations.
"Nann" is less used as it's the negative answer to a negatively phrased
question
See https://en.wikipedia.org/wiki/Yes_and_no for explanations about
languages with 3 or 4 form systems.
We still keep "Nn" for short answers as:
- new learners are used to "Non" in french
- and they often misuses "Nann"
- for compatibility with english
Carlos O'Donell [Tue, 17 Oct 2017 08:33:42 +0000 (01:33 -0700)]
localedef: Add --no-warnings/--warnings option
From localedef --help:
Output control:
...
--no-warnings=<warnings> Comma-separated list of warnings to disable;
supported warnings are: ascii, intcurrsym
...
--warnings=<warnings> Comma-separated list of warnings to enable;
supported warnings are: ascii, intcurrsym
Locales using SHIFT_JIS and SHIFT_JISX0213 character maps are not ASCII
compatible. In order to build locales using these character maps, and
have localedef exit with a status of 0, we add new option to localedef
to disable or enable specific warnings. The options are --no-warnings
and --warnings, to disable and enable specific warnings respectively.
The options take a comma-separated list of warning names. The warning
names are taken directly from the generated warning. When a warning
that can be disabled is issued it will print something like this: foo is
not defined [--no-warnings=foo]
For the initial implementation we add two controllable warnings; first
'ascii' which is used by the localedata installation makefile target to
install SHIFT_JIS and SHIFT_JISX0213-using locales without error; second
'intcurrsym' which allows a program to use a non-standard international
currency symbol without triggering a warning. The 'intcurrsym' is
useful in the future if country codes are added that are not in our
current ISO 4217 list, and the user wants to avoid the warning. Having
at least two warnings to control gives an example for how the changes
can be extended to more warnings if required in the future.
These changes allow ja_JP.SHIFT_JIS and ja_JP.SHIFT_JISX0213 to be
compiled without warnings using --no-warnings=ascii. The
localedata/Makefile $(INSTALL-SUPPORTED-LOCALES) target is adjusted to
automatically add `--no-warnings=ascii` for such charmaps, and likewise
localedata/gen-locale.sh is adjusted with similar logic.
v2: Bring verbose, be_quiet, and all warning control booleans into
record-status.c, and compile this object file to be used by locale,
iconv, and localedef. Any users include record-status.h.
v3: Fix an instance of boolean coercion in set_warning().
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Carlos O'Donell [Sat, 14 Oct 2017 05:44:44 +0000 (22:44 -0700)]
localedata: Locale and test name are the same.
The localedata collation test data is encoded in a particular
character set. We rename the test data to match the full locale
name with encoding, and adjust the Makefile and sort-test.sh
script. This allows us to have a future C.UTF-8 test that is
disambiguated from the built-in C locale.
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Carlos O'Donell [Wed, 25 Oct 2017 16:06:45 +0000 (09:06 -0700)]
localedata: Fix unicode-gen check target.
After the transition to generating a distinct file for Unicode ctype
information e.g. i18n_ctype, the check target was left with the wrong
target name. This patch fixes the check target and regenerates the
files with more information than previously used, filling in the the
LC_IDENTIFICATION data.
Tested on x86_64 by regenerating from Unicode source files, and
running checks. Tested by subsequently rebuilding all locales.
No regressions in testsuite.
Signed-off-by: Carlos O'Donell <carlos@redhat.com> Reported-by: Rafal Luzynski <digitalfreak@lingonborough.com>
powerpc: Replace lxvd2x/stxvd2x with lvx/stvx in P7's memcpy/memmove
POWER9 DD2.1 and earlier has an issue where some cache inhibited
vector load traps to the kernel, causing a performance degradation. To
handle this in memcpy and memmove, lvx/stvx is used for aligned
addresses instead of lxvd2x/stxvd2x.
Mike FABIAN [Wed, 25 Oct 2017 08:06:31 +0000 (10:06 +0200)]
hi_IN, kn_IN, ks_IN@devanagari locales: In yesexpr and noexpr, also check for the first characters of yesstr and nostr
* localedata/locales/hi_IN (LC_MESSAGES): In yesexpr and noexpr,
also check for the first characters of yesstr and nostr.
* localedata/locales/kn_IN (LC_MESSAGES): Likewise.
* localedata/locales/ks_IN@devanagari (LC_MESSAGES): Likewise.
Mike FABIAN [Wed, 25 Oct 2017 07:56:21 +0000 (09:56 +0200)]
chr_US locale: Fix yesexpr and noexpr
* localedata/locales/chr_US (LC_MESSAGES): In yesexpr and noexpr,
match also for the contents of yesstr and nostr. As the first letter
of yesstr and nostr is equal, checking only for the first letter
is not enough.
Mike FABIAN [Wed, 25 Oct 2017 06:34:21 +0000 (08:34 +0200)]
ug_CN locale: Fix noexpr and yesexpr
* localedata/locales/ug_CN (LC_MESSAGES): Fix noexpr and yesexpr
by including the first letters of nostr and yesexpr in the regexp.
Also make it more readable by using ASCII where possible.
Mike FABIAN [Wed, 25 Oct 2017 06:17:24 +0000 (08:17 +0200)]
ti_IN locale: Fix noexpr
* localedata/locales/te_IN (LC_MESSAGES): Fix noexpr by including
the first letter of nostr in the regexp. It agrees with CLDR now.
Also make it more readable by using ASCII where possible.
Mike FABIAN [Tue, 24 Oct 2017 14:37:36 +0000 (16:37 +0200)]
km_KH locale: Fix yesstr and nostr.
* localedata/locales/km_KH (LC_MESSAGES): Fix yestr and nostr.
The yesstr and nostr apparently came from CLDR. And CLDR has a bug there:
these strings contain a U+17D6 (which somewhat looks like a colon)
instead of a real colon to separate the full words for “yes”
and “no” from the single letter responses.
Mike FABIAN [Tue, 24 Oct 2017 14:20:55 +0000 (16:20 +0200)]
ka_GE locale: Fix yesexp to make it agree with CLDR.
* localedata/locales/ka_GE (LC_MESSAGES): Fix yesexp to make
it agree with CLDR (include the first letter of yesstr).
Also make it more readable by using ASCII where possible.
Mike FABIAN [Tue, 24 Oct 2017 12:06:05 +0000 (14:06 +0200)]
mr_IN locale: Fix yesstr and nostr and improve yesexpr and noexpr.
* localedata/locales/mr_IN (LC_MESSAGES): Fix yesstr and nostr
and improve yesexpr and noexpr. The yesstr and nostr apparently
came from CLDR. And CLDR has a bug there: these strings contain
a U+0903 (which looks like a colon) instead of a real colon
to separate the full words for “yes” and “no” from the single
letter responses.
Mike FABIAN [Tue, 24 Oct 2017 09:56:18 +0000 (11:56 +0200)]
bn_BD locale: Use only the first letters of the full yesstr and nostr in yesexpr and noexpr
Using all characters of the full words for yes and no in yesexpr and noexpr
makes no sense here, especially not because the words for yes and no
share one character.
* localedata/locales/bn_BD (LC_MESSAGES): Use only the first
letters of the full yesstr and nostr in yesexpr and noexpr.
Mike FABIAN [Tue, 24 Oct 2017 07:07:18 +0000 (09:07 +0200)]
Add yesstr, nostr, lang_term, lang_lib to an_ES locale
* localedata/locales/an_ES (LC_MESSAGES): Add yesstr and nostr.
* localedata/locales/an_ES (LC_ADDRESS): Add lang_term and lang_lib.
* localedata/locales/an_ES: Make source more readable by using ASCII
where possible.
Wilco Dijkstra [Tue, 24 Oct 2017 11:39:24 +0000 (12:39 +0100)]
Add single-threaded path to malloc/realloc/calloc/memalloc
This patch adds a single-threaded fast path to malloc, realloc,
calloc and memalloc. When we're single-threaded, we can bypass
arena_get (which always locks the arena it returns) and just use
the main arena. Also avoid retrying a different arena since
there is just the main arena.
Mike FABIAN [Mon, 23 Oct 2017 17:19:21 +0000 (19:19 +0200)]
Fixes for tpi_PG locale
* localedata/locales/tpi_PG (LC_MESSAGES): Fix yesexpr and noexpr
by adding the generic +1 and -0 as in all other locales.
* localedata/locales/tpi_PG (LC_TIME): Fix some typos in the month and
day names and make it more readable by using ASCII where possible.
Joseph Myers [Tue, 24 Oct 2017 00:33:08 +0000 (00:33 +0000)]
Update x86 fix-fp-int-compare-invalid.h for GCC 8.
The glibc implementation of iseqsig relies on ordered comparison
operators raising the "invalid" exception for quiet NaN operands, with
a workaround on platforms where a GCC bug means that exception is not
raised. For x86, that bug has now been fixed for GCC 8, so this patch
disables the workaround in that case. If and when the corresponding
bugs for powerpc and s390 are fixed, the headers for those platforms
should of course be updated similarly.
Tested for x86_64 and x86, including with GCC mainline. Note that
other failures appear with GCC mainline because of spurious use of
ordered comparison instructions for unordered operations
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82692>.
* sysdeps/x86/fpu/fix-fp-int-compare-invalid.h
(FIX_COMPARE_INVALID): Define to 0 if [__GNUC_PREREQ (8, 0)].
posix: Do not use WNOHANG in waitpid call for Linux posix_spawn
As shown in some buildbot issues on aarch64 and powerpc, calling
clone (VFORK) and waitpid (WNOHANG) does not guarantee the child
is ready to be collected. This patch changes the call back to 0
as before fe05e1cb6d64 fix.
This change can lead to the scenario 4.3 described in the commit,
where the waitpid call can hang undefinitely on the call. However
this is also a very unlikely and also undefinied situation where
both the caller is trying to terminate a pid before posix_spawn
returns and the race pid reuse is triggered. I don't see how to
correct handle this specific situation within posix_spawn.
Checked on x86_64-linux-gnu, aarch64-linux-gnu and
powerpc64-linux-gnu.
* sysdeps/unix/sysv/linux/spawni.c (__spawnix): Use 0 instead of
WNOHANG in waitpid call.
The _SC_LEVEL1_DCACHE_LINESIZE is reported using the contents of the
ctr_el0 register, which tells us the minimum observable cache line
size by userspace. This typically is the same as the L1 cache line
size, but that may not always be true. It could be a higher level
cache line size as long as cache cleaning and invalidation work
correctly with that line size in userspace. The falkor core for
example reports the L2 line size as the dcache line size in CTR_EL0
while also reporting the correct L1 dcache line size via CCSIDR_EL1.
Alan Modra [Sun, 22 Oct 2017 21:14:50 +0000 (07:44 +1030)]
PowerPC64 power8 strncpy cfi fixes
cfi info for stack adjust needs to be on the insn doing the adjust.
cfi describing register saves can be anywhere after the save insn but
before the reg is altered. Fewer locations with cfi result in smaller
cfi programs and possibly slightly faster exception handling. Thus
the LR cfi_offset move.
The idea behind ajusting sp after restoring regs is to break a
register dependency chain, in this case not be using r1 immediately
after it is modified.
The missing LR cfi_restore meant that code after the blr,
unaligned_lt_16 and other labels, would have cfi that said LR was at
cfa+16, but that code is reached without LR being saved.
* sysdeps/powerpc/powerpc64/power8/strncpy.S: Move LR cfi.
Adjust stack after restoring regs. Add missing LR cfi_restore.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
Alan Modra [Sun, 22 Oct 2017 21:13:32 +0000 (07:43 +1030)]
PowerPC64 power7 strncpy stack handling and cfi
This patch moves the frame setup and teardown to immediately around
the single memset call, as has been done for power8. I've also
decreased FRAMESIZE to that needed to save the two callee-saved
registers used. Plus added cfi.
* sysdeps/powerpc/powerpc64/power7/strncpy.S: Decrease FRAMESIZE.
Move LR save and frame setup/teardown and LR restore to
immediately around memset call. Provide cfi.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
Joseph Myers [Fri, 20 Oct 2017 21:42:51 +0000 (21:42 +0000)]
Add bits/floatn.h defines for more _FloatN / _FloatNx types.
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.
Avoid build multiarch if compiler warns about mismatched alias
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)
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:
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.
H.J. Lu [Fri, 20 Oct 2017 18:00:08 +0000 (11:00 -0700)]
x86-64: Use fxsave/xsave/xsavec in _dl_runtime_resolve [BZ #21265]
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:
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.
Will Hawkins [Fri, 20 Oct 2017 05:25:26 +0000 (22:25 -0700)]
resolv: Remove bogus targets that build ga_test
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
Florian Weimer [Fri, 20 Oct 2017 02:10:15 +0000 (04:10 +0200)]
sysconf: Fix missing definition of UIO_MAXIOV on Linux [BZ #22321]
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.
Joseph Myers [Thu, 19 Oct 2017 17:59:41 +0000 (17:59 +0000)]
Add MIPS bits/floatn.h.
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.
Joseph Myers [Thu, 19 Oct 2017 17:32:20 +0000 (17:32 +0000)]
Install correct bits/long-double.h for MIPS64 (bug 22322).
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>).
Wilco Dijkstra [Thu, 19 Oct 2017 17:19:55 +0000 (18:19 +0100)]
Fix deadlock in _int_free consistency check
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.
Joseph Myers [Wed, 18 Oct 2017 17:37:18 +0000 (17:37 +0000)]
Add _Float128 function aliases.
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.
Szabolcs Nagy [Wed, 18 Oct 2017 16:26:23 +0000 (17:26 +0100)]
[AARCH64] Rewrite elf_machine_load_address using _DYNAMIC symbol
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.
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>
Mike FABIAN [Wed, 18 Oct 2017 12:27:44 +0000 (14:27 +0200)]
Use U+202F NARROW NO-BREAK SPACE as thousands separators in pl_PL locale [BZ #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.
Joseph Myers [Tue, 17 Oct 2017 20:16:01 +0000 (20:16 +0000)]
Use __f128 to define FLT128_* constants in include/float.h for old GCC.
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.
Wilco Dijkstra [Tue, 17 Oct 2017 17:55:16 +0000 (18:55 +0100)]
Improve malloc initialization sequence
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!).
Wilco Dijkstra [Tue, 17 Oct 2017 17:43:31 +0000 (18:43 +0100)]
Use relaxed atomics for malloc have_fastchunks
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.
Wilco Dijkstra [Tue, 17 Oct 2017 17:25:43 +0000 (18:25 +0100)]
Inline tcache functions
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.
Aurelien Jarno [Thu, 30 Jun 2016 10:57:32 +0000 (12:57 +0200)]
New locale ca_ES@valencia [BZ #2522]
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.
Romain Naour [Mon, 16 Oct 2017 21:21:56 +0000 (23:21 +0200)]
Let signbit use the builtin in C++ mode with gcc < 6.x (bug 22296)
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>
Mike FABIAN [Tue, 17 Oct 2017 12:54:53 +0000 (14:54 +0200)]
Place monetary symbol in el_GR and el_CY after the amount
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.
Joseph Myers [Mon, 16 Oct 2017 22:04:42 +0000 (22:04 +0000)]
Move some float128 symbol version definitions.
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>
Florian Weimer [Mon, 16 Oct 2017 18:52:34 +0000 (20:52 +0200)]
malloc: Use compat_symbol_reference in libmcheck [BZ #22050]
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.
Joseph Myers [Mon, 16 Oct 2017 13:28:30 +0000 (13:28 +0000)]
Support running libm tests for float128 as alias for long double.
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.
Joseph Myers [Mon, 16 Oct 2017 13:22:11 +0000 (13:22 +0000)]
Support strtof128 etc. aliases.
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].
Carlos O'Donell [Sat, 14 Oct 2017 22:38:05 +0000 (15:38 -0700)]
locale: Don't use \n with record_verbose messages.
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>
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;
git://sourceware.org / glibc.git / log