aboutsummaryrefslogtreecommitdiff
path: root/elf/vismod.h
diff options
context:
space:
mode:
authorJoseph Myers <joseph@codesourcery.com>2017-08-31 15:50:50 +0000
committerJoseph Myers <joseph@codesourcery.com>2017-08-31 15:50:50 +0000
commita60eca2e55e2372e21f0d19b1dc5cac61a48ee50 (patch)
treef5985e97cda80421a27a53697bb1adc75f1572cc /elf/vismod.h
parent17e00cc69eac2ec10ac69a3f85db0dffc9d73845 (diff)
downloadglibc-a60eca2e55e2372e21f0d19b1dc5cac61a48ee50.tar
glibc-a60eca2e55e2372e21f0d19b1dc5cac61a48ee50.tar.gz
glibc-a60eca2e55e2372e21f0d19b1dc5cac61a48ee50.tar.bz2
glibc-a60eca2e55e2372e21f0d19b1dc5cac61a48ee50.zip
Simplify HUGE_VAL definitions.
There are various bits/huge_val*.h headers to define HUGE_VAL and related macros. All of them use __builtin_huge_val etc. for GCC 3.3 and later. Then there are various fallbacks, such as using a large hex float constant for GCC 2.96 and later, or using unions (with or without compound literals) to construct the bytes of an infinity, with this last being the reason for having architecture-specific files. Supporting TS 18661-3 _FloatN / _FloatNx types that have the same format as other supported types will mean adding more such macros; needing to add more headers for them doesn't seem very desirable. The fallbacks based on bytes of the representation of an infinity do not meet the standard requirements for a constant expression. At least one of them is also wrong: sysdeps/sh/bits/huge_val.h is producing a mixed-endian representation which does not match what GCC does. This patch eliminates all those headers, defining the macros directly in math.h. For GCC 3.3 and later, the built-in functions are used as now. For other compilers, a large constant 1e10000 (with appropriate suffix) is used. This is like the fallback for GCC 2.96 and later, but without using hex floats (which have no apparent advantage here). It is unambiguously valid standard C for all floating-point formats with infinities, which covers all formats supported by glibc or likely to be supported by glibc in future (C90 DR#025 said that if a floating-point format represents infinities, all real values lie within the range of representable values, so the constraints for constant expressions are not violated), but may generate compiler warnings and wouldn't handle the TS 18661-1 FENV_ROUND pragma correctly. If someone is actually using a compiler with glibc that does not claim to be GCC 3.3 or later, but which has a better way to define the HUGE_VAL macros, we can always add compiler conditionals in with alternative definitions. I intend to make similar changes for INF and NAN. The SNAN macros already just use __builtin_nans etc. with no fallback for compilers not claiming to be GCC 3.3 or later. Tested for x86_64. * math/math.h: Do not include bits/huge_val.h, bits/huge_valf.h, bits/huge_vall.h or bits/huge_val_flt128.h. (HUGE_VAL): Define directly here. [__USE_ISOC99] (HUGE_VALF): Likewise. [__USE_ISOC99] (HUGE_VALL): Likewise. [__HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (HUGE_VAL_F128): Likewise. * math/Makefile (headers): Remove bits/huge_val.h, bits/huge_valf.h, bits/huge_vall.h and bits/huge_val_flt128.h. * bits/huge_val.h: Remove. * bits/huge_val_flt128.h: Likewise. * bits/huge_valf.h: Likewise. * bits/huge_vall.h: Likewise. * sysdeps/ia64/bits/huge_vall.h: Likewise. * sysdeps/ieee754/bits/huge_val.h: Likewise. * sysdeps/ieee754/bits/huge_valf.h: Likewise. * sysdeps/m68k/m680x0/bits/huge_vall.h: Likewise. * sysdeps/sh/bits/huge_val.h: Likewise. * sysdeps/sparc/bits/huge_vall.h: Likewise. * sysdeps/x86/bits/huge_vall.h: Likewise.
Diffstat (limited to 'elf/vismod.h')
0 files changed, 0 insertions, 0 deletions