Here is an optimized implementation of __strchrnul. The
simplification that we don't have to track precisely why the loop
terminates (match or end-of-string) means we have to do less work in
both setup and the core inner loop. That means this should never be
slower than strchr.
As with strchr, the use of LD1 means we do not need different versions
for big-/little-endian.
Concluding the move of syscall definitions to syscalls.list, where the
removal of support for old kernel versions has made this possible,
this patch removes C definitions of pread, pread64, pwrite and
pwrite64 for powerpc64. As far as I can tell, the existing
syscalls.list definitions in
sysdeps/unix/sysv/linux/wordsize-64/syscalls.list should suffice to
produce results equivalent to what these C files do.
[BZ #14138]
* sysdeps/unix/sysv/linux/powerpc/powerpc64/pread.c: Remove file.
* sysdeps/unix/sysv/linux/powerpc/powerpc64/pread64.c: Likewise.
* sysdeps/unix/sysv/linux/powerpc/powerpc64/pwrite.c: Likewise.
* sysdeps/unix/sysv/linux/powerpc/powerpc64/pwrite64.c: Likewise.
In the Linux kernel version 3.17 the signal numbers were rearranged in
order to make hppa like every other arch. Previously we started
__SIGRTMIN at 37, and that meant several pieces of important software,
including systemd, would fail to build. To support systemd we removed
SIGEMT and SIGLOST, and rearranged the others according to expected
values. This is technically an ABI incompatible change, but because
zero applications use SIGSTKFLT, SIGXCPU, SIGXFSZ and SIGSYS nothing
broke. Nothing uses SIGEMT and SIGLOST, and they were present for
HPUX compatibility which is no longer supported. Thus because nothing
breaks we don't do any compatibility work here.
Upstream kernel commit is 1f25df2eff5b25f52c139d3ff31bc883eee9a0ab.
Signed-off-by: Carlos O'Donell <carlos@systemhalted.org>
Signed-off-by: Helge Deller <deller@gmx.de>
2014-10-23 Carlos O'Donell <carlos@systemhalted.org>
Helge Deller <deller@gmx.de>
[BZ #17508]
* sysdeps/unix/sysv/linux/hppa/bits/signum.h: Remove SIGEMT.
Define SIGSTKFLT as 7. Define SIGSYS as 31. Define SIGXCPU as 12.
Remove SIGLOST. Define SIGXFSZ as 30. Define __SIGRTMIN as 32.
This satisfies a symbol reference created with:
.symver __libc_vfork, vfork@GLIBC_2.0
where `__libc_vfork' has not been defined or referenced. In this case
the `vfork@GLIBC_2.0' reference is supposed to be discarded, however a
bug present in GAS since forever causes an undefined symbol table entry
to be created. This in turn triggers a problem in the linker that can
manifest itself by link errors such as:
ld: libpthread.so: invalid string offset 2765592330 >= 5154 for section `.dynstr'
The GAS and linker bugs need to be resolved, but we can avoid them too
by providing a `__libc_vfork' definition just like our other platforms.
[BZ #17485]
* sysdeps/unix/sysv/linux/mips/vfork.S (__libc_vfork): Define.
this is a path that should solve bug 15884. It complains about the performance
of strcoll(). It was found out that the runtime of strcoll() is actually bound
to strlen which is needed for calculating the size of a cache that was
installed to improve the comparison performance.
The idea for this patch was that the cache is only useful in rare cases
(strings of same length and same first-level-chars) and that it would be
better to avoid memory allocation at all. To prove this I wrote a performance
test bench-strcoll.c with test data in benchtests-strcoll.tar.gz. Also
modifications in benchtests/Makefile and localedata/Makefile are necessary to
make it work.
After removing the cache the strcoll method showed the predicted behavior
(getting slightly faster) in all but the test case for hindi word sorting.
This was due the hindi text having much more equal words than the other ones.
For equal strings the performance was worse since all comparison levels were
run through and from the second level on the cache improved the comparison
performance of the original version.
Therefore I added a bytewise test via strcmp iff the first level comparison
found that both strings did match because in this case it is very likely that
equal strings are compared. This solved the problem with the hindi test case
and improved the performance of the others.
Performance comparison:
glibc files -33.77%
vi_VN.UTF-8 -34.12%
en_US.UTF-8 -42.42%
ar_SA.UTF-8 -27.49%
zh_CN.UTF-8 +07.90%
cs_CZ.UTF-8 -29.67%
en_GB.UTF-8 -28.50%
da_DK.UTF-8 -36.57%
pl_PL.UTF-8 -39.31%
fr_FR.UTF-8 -28.57%
pt_PT.UTF-8 -22.82%
el_GR.UTF-8 -26.77%
ru_RU.UTF-8 -35.81%
iw_IL.UTF-8 -35.34%
es_ES.UTF-8 -34.46%
hi_IN.UTF-8 -00.38%
sv_SE.UTF-8 -36.99%
hu_HU.UTF-8 -16.35%
tr_TR.UTF-8 -27.80%
is_IS.UTF-8 -33.24%
it_IT.UTF-8 -24.39%
sr_RS.UTF-8 -37.55%
ja_JP.UTF-8 +02.84%
The recvmsg could return 0 under some conditions and cause the
make_request function to be stuck in an infinite loop.
Thank you Jim King <jim.king@simplivity.com> for posting Paul's patch
on the list.
During auditing or profiling modes the dynamic loader
builds a cache of the relocated PLT entries in order
to reuse them when called again through the same PLT
entry. This way the PLT entry is never completed and
the call into the resolver always results in profiling
or auditing code running.
The problem is that the PLT relocation cache size
is not computed correctly. The size of the cache
should be "Size of a relocation result structure"
x "Number of PLT-related relocations". Instead the
code erroneously computes "Size of a relocation
result" x "Number of bytes worth of PLT-related
relocations". I can only assume this was a mistake
in the understanding of the value of DT_PLTRELSZ
which is the number of bytes of PLT-related relocs.
We do have a DT_RELACOUNT entry, which is a count
for dynamic relative relocs, but we have no
DT_PLTRELCOUNT and thus we need to compute it.
This patch corrects the computation of the size of the
relocation table used by the glibc profiling code.
For more details see:
https://sourceware.org/ml/libc-alpha/2014-09/msg00513.html
[BZ #17411]
* elf/dl-reloc.c (_dl_relocate_object): Allocate correct amount for
l_reloc_result.
This patch eliminates the mixture of SONAME information in
shlib-versions files and SONAME information used to generate
gnu/lib-names.h in makefiles, with the information in the makefiles
being removed so all this information comes from the shlib-versions
files.
So that gnu/lib-names.h supports multiple ABIs, it is changed to be
generated on the same basis as gnu/stubs.h: when there are multiple
ABIs, gnu/lib-names.h is a wrapper header (the same header installed
whatever ABI is being built) and separate headers such as
gnu/lib-names-64.h contain the substantive contents (only one such
header being installed by any glibc build).
The rules for building gnu/lib-names.h were moved from Makeconfig to
Makerules because they need to come after sysdeps makefiles are
included (now that "ifndef abi-variants" is a toplevel conditional on
the rules rather than $(abi-variants) being evaluated later inside the
commands for a rule).
Tested for x86_64 and x86 that the installed shared libraries are
unchanged by this patch, and examined the installed gnu/lib-names*.h
headers by hand. Also tested the case of a single ABI (where there is
just a single header installed, again like stubs.h) by hacking
abi-variants to empty for x86_64.
[BZ #14171]
* Makeconfig [$(build-shared) = yes]
($(common-objpfx)soversions.mk): Don't handle SONAMEs specified in
makefiles.
[$(build-shared) = yes && $(soversions.mk-done) = t]
($(common-objpfx)gnu/lib-names.h): Remove rule.
[$(build-shared) = yes && $(soversions.mk-done) = t]
($(common-objpfx)gnu/lib-names.stmp): Likewise. Split and moved
to Makerules.
[$(build-shared) = yes && $(soversions.mk-done) = t]
(before-compile): Don't append $(common-objpfx)gnu/lib-names.h
here.
[$(build-shared) = yes && $(soversions.mk-done) = t]
(common-generated): Don't append gnu/lib-names.h and
gnu/lib-names.stmp here.
* Makerules [$(build-shared) = yes && $(soversions.mk-done) = t]
(lib-names-h-abi): New variable.
[$(build-shared) = yes && $(soversions.mk-done) = t]
(lib-names-stmp-abi): Likewise.
[$(build-shared) = yes && $(soversions.mk-done) = t &&
abi-variants] (before-compile): Append
$(common-objpfx)$(lib-names-h-abi).
[$(build-shared) = yes && $(soversions.mk-done) = t &&
abi-variants] (common-generated): Append gnu/lib-names.h.
[$(build-shared) = yes && $(soversions.mk-done) = t &&
abi-variants] (install-others-nosubdir): Depend on
$(inst_includedir)/$(lib-names-h-abi).
[$(build-shared) = yes && $(soversions.mk-done) = t &&
abi-variants] ($(common-objpfx)gnu/lib-names.h): New rule.
[$(build-shared) = yes && $(soversions.mk-done) = t]
($(common-objpfx)$(lib-names-h-abi)): New rule.
[$(build-shared) = yes && $(soversions.mk-done) = t]
($(common-objpfx)$(lib-names-stmp-abi)): Likewise.
[$(build-shared) = yes && $(soversions.mk-done) = t]
(common-generated): Append $(lib-names-h-abi) and
$(lib-names-stmp-abi).
* scripts/lib-names.awk: Do not handle multi being set.
* sysdeps/unix/sysv/linux/aarch64/Makefile (abi-lp64-ld-soname):
Remove variable.
(abi-lp64_be-ld-soname): Likewise.
* sysdeps/unix/sysv/linux/arm/Makefile (abi-soft-ld-soname):
Likewise.
(abi-hard-ld-soname): Likewise.
* sysdeps/unix/sysv/linux/i386/shlib-versions: New file.
* sysdeps/unix/sysv/linux/mips/Makefile (abi-o32_soft-ld-soname):
Remove variable.
(abi-o32_hard-ld-soname): Likewise.
(abi-o32_soft_2008-ld-soname): Likewise.
(abi-o32_hard_2008-ld-soname): Likewise.
(abi-n32_soft-ld-soname): Likewise.
(abi-n32_hard-ld-soname): Likewise.
(abi-n32_soft_2008-ld-soname): Likewise.
(abi-n32_hard_2008-ld-soname): Likewise.
(abi-n64_soft-ld-soname): Likewise.
(abi-n64_hard-ld-soname): Likewise.
(abi-n64_soft_2008-ld-soname): Likewise.
(abi-n64_hard_2008-ld-soname): Likewise.
* sysdeps/unix/sysv/linux/powerpc/Makefile (abi-64-v1-ld-soname):
Likewise.
(abi-64-v2-ld-soname): Likewise.
* sysdeps/unix/sysv/linux/powerpc/powerpc64/shlib-versions: Add
ld.so entries.
* sysdeps/unix/sysv/linux/s390/Makefile (abi-64-ld-soname): Remove
variable.
* sysdeps/unix/sysv/linux/s390/s390-64/shlib-versions: Add ld.so
entry.
* sysdeps/unix/sysv/linux/x86/Makefile (abi-32-ld-soname): Remove
variable.
(abi-64-ld-soname): Likewise.
(abi-x32-ld-soname): Likewise.
* sysdeps/unix/sysv/linux/x86_64/64/shlib-versions: Add ld.so
entry.
* sysdeps/unix/sysv/linux/x86_64/x32/shlib-versions: Likewise.
This patch removes the --enable-oldest-abi configure option, which has
long been bitrotten (as reported in bug 6652). The principle of
removing this option was agreed in the thread starting at
<https://sourceware.org/ml/libc-alpha/2013-07/msg00174.html>.
Tested for x86_64 and x86 that the installed shared libraries other
than libc.so are unchanged by this patch and that libc.so disassembly
and symbol versions are unchanged (debug info changes because of
changed line numbers in csu/version.c).
[BZ #6652]
* Makeconfig (soversions-default-setname): Remove variable.
($(common-objpfx)soversions.i): Don't pass default_setname to
soversions.awk.
* Makerules ($(common-objpfx)abi-versions.h): Don't pass
oldest_abi to abi-versions.awk.
* config.h.in (GLIBC_OLDEST_ABI): Remove macro undefine.
* config.make.in (oldest-abi): Remove variable.
* configure.ac (--enable-oldest-abi): Remove configure option.
* configure: Regenerated.
* csu/version.c (banner) [GLIBC_OLDEST_ABI]: Remove conditional
text.
* scripts/abi-versions.awk: Do not handle oldest_abi variable.
* scripts/soversions.awk: Do not handle default_setname variable.
* sysdeps/mach/hurd/configure.ac: Do not handle oldest_abi
variable.
* sysdeps/mach/hurd/configure: Regenerated.
* sysdeps/unix/sysv/linux/configure.ac: Do not handle oldest_abi
variable.
* sysdeps/unix/sysv/linux/configure: Regenerated.
The netgroups lookup code fails when one of the groups in the search
tree is empty. In such a case it only returns the leaves of the tree
after the blank netgroup. This is because the line parser returns a
NOTFOUND status when the netgroup exists but is empty. The
__getnetgrent_internal implementation needs to be fixed to try
remaining groups if the current group is entry. This patch implements
this fix. Tested on x86_64.
[BZ #17363]
* inet/getnetgrent_r.c (__internal_getnetgrent_r): Try next
group if the current group is empty.
Some types of relocations technically need to be signed rather than
unsigned: in particular ones that are used with moveli or movei,
or for jump and branch. This is almost never a problem. Jump and
branch opcodes are pretty much uniformly resolved by the static linker
(unless you omit -fpic for a shared library, which is not recommended).
The moveli and movei opcodes that need to be sign-extended generally
are for positive displacements, like the construction of the address of
main() from _start(). However, tst-pie1 ends up with main below _start
(in a different module) and the test failed due to signedness issues in
relocation handling.
This commit treats the value as signed when shifting (to preserve the
high bit) and also sign-extends the value generated from the updated
bundle when comparing with the desired bundle, which we do to make sure
no overflow occurred. As a result, the tst-pie1 test now passes.
TLS_INIT_TP in sysdeps/i386/nptl/tls.h uses some hand written asm to
generate a set_thread_area that might result in exchanging ebx and esp
around the syscall causing introspection tools like valgrind to loose
track of the user stack. Just use INTERNAL_SYSCALL which makes sure
esp isn't changed arbitrarily.
Before the patch the code would generate:
mov $0xf3,%eax
movl $0xfffff,0x8(%esp)
movl $0x51,0xc(%esp)
xchg %esp,%ebx
int $0x80
xchg %esp,%ebx
Using INTERNAL_SYSCALL instead will generate:
movl $0xfffff,0x8(%esp)
movl $0x51,0xc(%esp)
xchg %ecx,%ebx
mov $0xf3,%eax
int $0x80
xchg %ecx,%ebx
Thanks to Florian Weimer for analysing why the original code generated
the bogus esp usage:
_segdescr.desc happens to be at the top of the stack, so its address
is in %esp. The asm statement says that %3 is an input, so its value
will not change, and GCC can use %esp as the input register for the
expression &_segdescr.desc. But the constraints do not fully describe
the asm statement because the %3 register is actually modified, albeit
only temporarily.
[BZ #17319]
* sysdeps/i386/nptl/tls.h (TLS_INIT_TP): Use INTERNAL_SYSCALL
to call set_thread_area instead of hand written asm.
(__NR_set_thread_area): Removed define.
(TLS_FLAG_WRITABLE): Likewise.
(__ASSUME_SET_THREAD_AREA): Remove check.
(TLS_EBX_ARG): Remove define.
(TLS_LOAD_EBX): Likewise.
In my powerpc32 testing I've observed misc/test-gettimebasefreq
failing.
This is a glibc build (soft-float, though that's not relevant here)
without any --with-cpu and without any special configuration of the
default CPU for GCC either. In particular, it's one not using
sysdeps/powerpc/powerpc32/power4/hp-timing.h (although in fact the
processor I'm using for testing is POWER4-based), so hp_timing_t is
32-bit not 64-bit. But the VDSO call being used by
INTERNAL_VSYSCALL_NO_SYSCALL_FALLBACK is generating a 64-bit result
(high part in r3, low part in r4). The code extracting that result,
however, expects a result of the type hp_timing_t as passed to
INTERNAL_VSYSCALL_NO_SYSCALL_FALLBACK, meaning that only r3 (= 0) is
used and the value in r4 is ignored. This patch fixes this by always
using uint64_t as the type in INTERNAL_VSYSCALL_NO_SYSCALL_FALLBACK -
reflecting the actual ABI (unconditional in the kernel) of that VDSO
call. This is the minimal change for this issue - no check for
overflow, no change of the type of the timebase_freq variable or the
return type of __get_clockfreq to something other than hp_timing_t
(such a change would simply move the implicit conversions to the over
callers of that function), no change to hp_timing_t itself.
Tested for powerpc32 soft float.
[BZ #17263]
* sysdeps/unix/sysv/linux/powerpc/get_clockfreq.c: Include
<stdint.h>.
(__get_clockfreq): Use uint64_t instead of hp_timing_t in
INTERNAL_VSYSCALL_NO_SYSCALL_FALLBACK call.
Since:
commit 409e00bd69
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Wed Jan 29 07:51:41 2014 -0800
Disable x87 inline functions for SSE2 math
When i386 and x86-64 mathinline.h was merged into a single mathinline.h,
"gcc -m32" enables x87 inline functions on x86-64 even when -mfpmath=sse
and SSE2 is enabled. It is a regression on x86-64. We should check
__SSE2_MATH__ instead of __x86_64__ when disabling x87 inline functions.
gcc-3.2 is unable to correctly compile x86_64 routines for llrint
since it gets redefined. This is because gcc 3.2 does not set
__SSE2_MATH__ for x86_64, thus exposing the duplicate definition.
The correct fix ought to be to check for both __SSE2_MATH__ and
__x86_64__ and enable those bits only when neither are defined.
Tested fix with the reproducer for
409e00bd69 as well as with gcc-3.2.
The compiler doesn't know that the cpuid asm statement in intel_check_word
will trash RBX. We are lucky that it doesn't cause any problems since
RBX is also used by compiler for other purposes so that RBX is saved and
restored. This patch replaces it with __cpuid_count.
[BZ #17259]
* sysdeps/x86_64/cacheinfo.c (intel_check_word): Replace cpuid
asm statement with __cpuid_count.
On powerpc, floating-point environment macros are defined as pointers
to constants in the library that contain the bit-patterns of the
desired environment, instead of being magic constants cast to pointer
type.
For soft-float, the bit-patterns used for fenv_t are not laid out the
same as for hard-float. (e500 has a third layout used; that's not an
ABI issue because these values are only meaningful within a single
process, all of whose glibc libraries must come from the same build of
glibc.) While the __fe_dfl_env value for soft-float was appropriate
for the soft-float fenv_t representation, the other two constants had
the same bit-patterns as for hard-float. Those bit patterns had the
effect of having exceptions already raised, causing
math/test-fenv-return to fail; this patch fixes the patterns used.
(__fe_nonieee_env also had exceptions unmasked, though they should be
masked to match hard-float semantics. Since there is no separate
non-IEEE mode for soft-float, it's most appropriate for
__fe_nonieee_env to be the same as __fe_dfl_env; this patch makes it
an alias.)
Tested for powerpc-nofpu.
[BZ #17261]
* sysdeps/powerpc/nofpu/fenv_const.c (__fe_enabled_env): Change
value to 0.
(__fe_nonieee_env): Define as an alias for __fe_dfl_env.
Open file description locks have been merged into the Linux kernel for
v3.15. Add the appropriate command-value definitions and an update to
the manual that describes their usage.
This is a change to the dynamic linker to add prelinker support for the
R_ARM_TLS_DESC relocation. Two cases can be considered here, the usual
one where lazy binding is in use and the less frequent one, where
immediate binding is requested via the use of the DF_BIND_NOW dynamic
flag (e.g. by using the GNU linker's "-z now" option).
This change only handles the first case. In this scenario the prelinker
does what the dynamic linker would do, that is it preinitialises
R_ARM_TLS_DESC relocations with a pointer to the lazy specialization as
provided with the DT_TLSDESC_PLT dynamic tag. A conflict is
additionally created and in the conflict resolution path the dynamic
linker complements the work by initialising the object's pointer as
indicated by the DT_TLSDESC_GOT dynamic tag to the linker's internal
lazy specialization worker function and also providing the associated
link map in the second entry of the GOT. This step is required, because
if prelinking is successful at the run time, then the dynamic linker's
elf_machine_runtime_setup() function isn't called that would normally do
so.
The second case remains unresolved, because support for that scenario
has not been implemented in the prelinker. In this case the lazy
specialization is unavailable and the DT_TLSDESC_PLT dynamic tag is not
present.
The prelinker could assume the common case of static specialization and
resolve the relocation, but that would require the exposure of dynamic
linker's specialization worker function. Furthermore the dynamic linker
would have to handle the relocation in the conflict resolution path and
see if the dynamic specialization should be used instead. This however
would require access to data structures currently not made available to
the conflict resolution path and therefore a redesign of this part of
the dynamic linker.
Alternatively the prelinker could defer all processing to the dynamic
linker's conflict resolution path, but that would require similar access
to the said data structures.
Therefore the prelinker issues an error instead and the dynamic linker
has assertions to check that DT_TLSDESC_PLT and DT_TLSDESC_GOT are in
use in its conflict resolution path.
This change resolves all TLS failures in the prelinker testsuite, as
noted in the bug report, as well as the small test case provided there.
Unfortunately we don't seem to have any hooks to factor in the prelinker
(if present on a system) to testing, so at this time this fix has to
rely on using the prelinker test suite and enabling TLS descriptors
there for coverage.
[BZ #17078]
* sysdeps/arm/dl-machine.h (elf_machine_rela)
[RESOLVE_CONFLICT_FIND_MAP]: Handle R_ARM_TLS_DESC relocation.
(elf_machine_lazy_rel): Handle prelinked R_ARM_TLS_DESC entries.
This patch fixes bug 17088, fallback fesetenv and feupdateenv not
giving an error for an FE_NOMASK_ENV argument when it requires traps
to be enabled. (This is the bug tested for by test-fenv-return.c.)
Tested mips64 soft-float.
[BZ #17088]
* math/fesetenv.c (__fesetenv)
[FE_NOMASK_ENV && FE_ALL_EXCEPT != 0]: Return 1 for FE_NOMASK_ENV.
* math/feupdateenv.c (__feupdateenv)
[FE_NOMASK_ENV && FE_ALL_EXCEPT != 0]: Likewise.
If a call to the set*id functions fails in a multi-threaded program,
the abort introduced in commit 13f7fe35ae
was triggered.
We address by checking that all calls to set*id on all threads give
the same result, and only abort if we see success followed by failure
(or vice versa).
Here's an updated patch to fix the crash in bug-ga2 when the system
has no configured ipv6 address. I have taken a different approach of
using libc_freeres_fn instead of the libc_freeres_ptr since the former
gives better control over what is freed; we need that since cache may
or may not be allocated using malloc.
Verified that bug-ga2 works correctly in both cases and does not have
memory leaks in either of them.
This patch fixes bug 17097, ldbl-128 powl producing overflowing /
underflowing results with positive sign when the result should have
been negative. This was shown up by the tests in non-default rounding
modes added by my patch for bug 16315, but isn't actually limited to
non-default rounding modes: rather, when rounding to nearest the
wrappers produced a result with the correct sign and so always hid the
bug unless -lieee was used to disable the wrappers. The problem is
that in the cases where Y is large enough that the result overflows or
underflows for X not very close to 1, but not large enough to overflow
or underflow for all X != +/- 1 (in the latter case Y is always an
even integer), a positive overflowing / underflowing result is always
returned, rather than one with the correct sign. This patch moves the
relevant part of computation of the sign earlier and returns a result
of the correct sign.
Tested for mips64.
[BZ #17097]
* sysdeps/ieee754/ldbl-128/e_powl.c (__ieee754_powl): Return
result with correct sign in case of exponents that produce
overflow except for X very close to 1.
The nscd parent process returns the result of a `wait' call rather
than the exit status of the child it waits for. These two aren't
exactly the same. In my case (and probably on most machines), the exit
status is in the 2nd LSB of the result of `wait', and so:
e.g. if the nscd child process returns 1, the parent returns 1 << 8,
which Bash happily reports as 0.
This patch fixes bugs 16561 and 16562, bad results of yn in overflow
cases in non-default rounding modes, both because an intermediate
overflow in the recurrence does not get detected if the result is not
an infinity and because an overflowing result may occur in the wrong
sign. The fix is to set FE_TONEAREST mode internally for the parts of
the function where such overflows can occur (which includes the call
to y1 - where yn is used to compute a Bessel function of order -1,
negating the result of y1 isn't correct for overflowing results in
directed rounding modes) and then compute an overflowing value in the
original rounding mode if the to-nearest result was an infinity.
Tested x86_64 and x86 and ulps updated accordingly. Also tested for
mips64 and powerpc32 to test the ldbl-128 and ldbl-128ibm changes.
(The tests for these bugs were added in my previous y1 patch, so the
only thing this patch has to do with the testsuite is enable yn
testing in all rounding modes.)
[BZ #16561]
[BZ #16562]
* sysdeps/ieee754/dbl-64/e_jn.c: Include <float.h>.
(__ieee754_yn): Set FE_TONEAREST mode internally and then
recompute overflowing results in original rounding mode.
* sysdeps/ieee754/flt-32/e_jnf.c: Include <float.h>.
(__ieee754_ynf): Set FE_TONEAREST mode internally and then
recompute overflowing results in original rounding mode.
* sysdeps/ieee754/ldbl-128/e_jnl.c: Include <float.h>.
(__ieee754_ynl): Set FE_TONEAREST mode internally and then
recompute overflowing results in original rounding mode.
* sysdeps/ieee754/ldbl-128ibm/e_jnl.c: Include <float.h>.
(__ieee754_ynl): Set FE_TONEAREST mode internally and then
recompute overflowing results in original rounding mode.
* sysdeps/ieee754/ldbl-96/e_jnl.c: Include <float.h>.
(__ieee754_ynl): Set FE_TONEAREST mode internally and then
recompute overflowing results in original rounding mode.
* sysdeps/i386/fpu/fenv_private.h [!__SSE2_MATH__]
(libc_feholdsetround_ctx): New macro.
* math/libm-test.inc (yn_test): Use ALL_RM_TEST.
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/x86_64/fpu/libm-test-ulps : Likewise.
This patch updates README to remove a mention of the ports directory.
It also adds a NEWS item for the merge of ports into the main sysdeps
tree (I think it's NEWS-worthy, although not strictly a user-visible
feature).
Other remaining ports references to resolve: a comment in
manual/signal.texi (not giving a literal path, but maybe should change
anyway); a comment in config.h.in (path should be updated);
scripts/list-sources.sh (appears to date back to ports being a
separate repository).
* README: Do not mention ports directory.
This patch fixes bug 16539, spurious underflow exceptions from x86 /
x86-64 expm1l. The problem is that the computation of a base-2
exponent with extra precision involves spurious underflows for
arguments that are small but not subnormal, so a check is added to
just return the argument in those cases. (If the argument *is*
subnormal, underflowing is correct and the existing code will always
underflow, so it suffices to keep using the existing code in that
case; some expm1 implementations have a bug (bug 16353) with missing
underflow exceptions, but I don't think there's such a bug in this
particular version.)
Tested x86_64 and x86; no ulps updates needed.
(auto-libm-test-out diffs omitted below.)
[BZ #16539]
* sysdeps/i386/fpu/e_expl.S (IEEE754_EXPL) [USE_AS_EXPM1L]: Just
return the argument for normal arguments with exponent below -64.
* sysdeps/x86_64/fpu/e_expl.S (IEEE754_EXPL) [USE_AS_EXPM1L]:
Likewise.
* math/auto-libm-test-in: Add another test of expm1.
* math/auto-libm-test-out: Regenerated.
This patch fixes bug 16287, spurious underflows from ldbl-128 erfl
arising from it calling erfcl for arguments with absolute value at
least 1.0, although for large positive arguments erfcl correctly
underflows but erfl shouldn't. The fix is simply to avoid calling
erfcl, and just return 1, for arguments above a cut-off large enough
that erfl correctly rounds to-nearest as 1 but not so large that erfcl
underflows.
Tested mips64. Also tested x86_64 and x86 to confirm the new tests
(taken from the tests of erfc) don't cause any problems there; no ulps
updates needed.
[BZ #16287]
* sysdeps/ieee754/ldbl-128/s_erfl.c (__erfl): Return 1 without
calling __erfcl for arguments at least 16.
* math/auto-libm-test-in: Add more tests of erf.
* math/auto-libm-test-out: Regenerated.
