| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Continuing the refactoring of bits/mathdef.h, this patch moves the
FP_FAST_* definitions into a new bits/fp-fast.h header. Currently
this is only for FP_FAST_FMA*, but in future it would be the
appropriate place for the FP_FAST_* macros from TS 18661-1 as well.
The generic bits/mathdef.h header defines these macros based on
whether the compiler defines __FP_FAST_*. Most architecture-specific
headers, however, fail to do so, meaning that if the architecture (or
some particular processors) does in fact have fused operations, and
GCC knows to use them inline, the FP_FAST_* macros will still not be
defined.
By refactoring, this patch causes the generic version (based on
__FP_FAST_*) to be used in more cases, and so the macro definitions to
be more accurate. Architectures that already defined some or all of
these macros other than based on the predefines have their own
versions of fp-fast.h, which are arranged so they define FP_FAST_* if
either the architecture-specific conditions are true or __FP_FAST_*
are defined.
After this refactoring, various bits/mathdef.h headers for
architectures with long double = double are semantically identical to
the generic version. The patch removes those headers that are
redundant. (In fact two of the four removed were already redundant
before this patch because they did use __FP_FAST_*.)
Tested for x86_64 and x86, and compilation-only with
build-many-glibcs.py.
* bits/fp-fast.h: New file.
* sysdeps/aarch64/bits/fp-fast.h: Likewise.
* sysdeps/powerpc/bits/fp-fast.h: Likewise.
* math/Makefile (headers): Add bits/fp-fast.h.
* math/math.h: Include <bits/fp-fast.h>.
* bits/mathdef.h (FP_FAST_FMA): Remove.
(FP_FAST_FMAF): Likewise.
(FP_FAST_FMAL): Likewise.
* sysdeps/aarch64/bits/mathdef.h (FP_FAST_FMA): Likewise.
(FP_FAST_FMAF): Likewise.
* sysdeps/powerpc/bits/mathdef.h (FP_FAST_FMA): Likewise.
(FP_FAST_FMAF): Likewise.
* sysdeps/x86/bits/mathdef.h (FP_FAST_FMA): Likewise.
(FP_FAST_FMAF): Likewise.
(FP_FAST_FMAL): Likewise.
* sysdeps/arm/bits/mathdef.h: Remove file.
* sysdeps/hppa/fpu/bits/mathdef.h: Likewise.
* sysdeps/sh/sh4/bits/mathdef.h: Likewise.
* sysdeps/tile/bits/mathdef.h: Likewise.
|
|
At present, definitions of float_t and double_t are split among many
bits/mathdef.h headers.
For all but three architectures, these types are float and double.
Furthermore, if you assume __FLT_EVAL_METHOD__ to be defined, that
provides a more generic way of determining the correct values of these
typedefs. Defining these typedefs more generally based on
__FLT_EVAL_METHOD__ was previously proposed by Paul Eggert in
<https://sourceware.org/ml/libc-alpha/2012-02/msg00002.html>.
This patch refactors things in the way I proposed in
<https://sourceware.org/ml/libc-alpha/2016-11/msg00745.html>. A new
header bits/flt-eval-method.h defines a single macro,
__GLIBC_FLT_EVAL_METHOD, which is then used by math.h to define
float_t and double_t. The default is based on __FLT_EVAL_METHOD__
(although actually a default to 0 would have the same effect for
current ports, because ports where values other than 0 or 16 are
possible all have their own headers).
To avoid changing the existing semantics in any case, including for
compilers not defining __FLT_EVAL_METHOD__, architecture-specific
files are then added for m68k, s390, x86 which replicate the existing
semantics. At least with __FLT_EVAL_METHOD__ values possible with
GCC, there should be no change to the choices of float_t and double_t
for any supported configuration.
Architecture maintainer notes:
* m68k: sysdeps/m68k/m680x0/bits/flt-eval-method.h always defines
__GLIBC_FLT_EVAL_METHOD to 2 to replicate the existing logic. But
actually GCC defines __FLT_EVAL_METHOD__ to 0 if TARGET_68040. It
might make sense to make the header prefer to base things on
__FLT_EVAL_METHOD__ if defined, like the x86 version, and so make
the choices of these types more accurate (with a NEWS entry as for
the other changes to these types on particular architectures).
* s390: sysdeps/s390/bits/flt-eval-method.h always defines
__GLIBC_FLT_EVAL_METHOD to 1 to replicate the existing logic. As
previously discussed, it might make sense in coordination with GCC
to eliminate the historic mistake, avoid excess precision in the
-fexcess-precision=standard case and make the typedefs match (with a
NEWS entry, again).
Tested for x86-64 and x86. Also did compilation-only testing with
build-many-glibcs.py.
* bits/flt-eval-method.h: New file.
* sysdeps/m68k/m680x0/bits/flt-eval-method.h: Likewise.
* sysdeps/s390/bits/flt-eval-method.h: Likewise.
* sysdeps/x86/bits/flt-eval-method.h: Likewise.
* math/Makefile (headers): Add bits/flt-eval-method.h.
* math/math.h: Include <bits/flt-eval-method.h>.
[__USE_ISOC99] (float_t): Define based on __GLIBC_FLT_EVAL_METHOD.
[__USE_ISOC99] (double_t): Likewise.
* bits/mathdef.h (float_t): Remove.
(double_t): Likewise.
* sysdeps/aarch64/bits/mathdef.h (float_t): Likewise.
(double_t): Likewise.
* sysdeps/alpha/bits/mathdef.h (float_t): Likewise.
(double_t): Likewise.
* sysdeps/arm/bits/mathdef.h (float_t): Likewise.
(double_t): Likewise.
* sysdeps/hppa/fpu/bits/mathdef.h (float_t): Likewise.
(double_t): Likewise.
* sysdeps/ia64/bits/mathdef.h (float_t): Likewise.
(double_t): Likewise.
* sysdeps/m68k/m680x0/bits/mathdef.h (float_t): Likewise.
(double_t): Likewise.
* sysdeps/mips/bits/mathdef.h (float_t): Likewise.
(double_t): Likewise.
* sysdeps/powerpc/bits/mathdef.h (float_t): Likewise.
(double_t): Likewise.
* sysdeps/s390/bits/mathdef.h (float_t): Likewise.
(double_t): Likewise.
* sysdeps/sh/sh4/bits/mathdef.h (float_t): Likewise.
(double_t): Likewise.
* sysdeps/sparc/bits/mathdef.h (float_t): Likewise.
(double_t): Likewise.
* sysdeps/tile/bits/mathdef.h (float_t): Likewise.
(double_t): Likewise.
* sysdeps/x86/bits/mathdef.h (float_t): Likewise.
(double_t): Likewise.
|
|
|
|
This avoids build failures in the tests, and matches what is in
bits/mathdef.h.
Update the libc and libm abilist files to include __finitel,
__isinfl, and __isnanl.
|
|
|
|
The macros are defined by the compiler, so we can only verify whether
they are defined or not.
|
|
I've moved the TILE-Gx and TILEPro ports to the main sysdeps hierarchy,
along with the linux-generic ports infrastructure. Beyond the README
update, the move was just
git mv ports/sysdeps/tile sysdeps/tile
git mv ports/sysdeps/unix/sysv/linux/tile \
sysdeps/unix/sysv/linux/tile
git mv ports/sysdeps/unix/sysv/linux/generic \
sysdeps/unix/sysv/linux/generic
I updated the relevant ChangeLogs along the lines of the ARM move
in commit c6bfe5c4d75 and tested the 64-bit tilegx build to confirm that
there were no changes in "objdump -dr" output in the shared objects.
|
