This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Adding __float128 (i.e TS 18661-3) [v2]
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Steve Munroe <sjmunroe at us dot ibm dot com>
- Date: Fri, 10 Jun 2016 17:23:52 +0000
- Subject: Re: Adding __float128 (i.e TS 18661-3) [v2]
- Authentication-results: sourceware.org; auth=none
- References: <572BB6DF dot 7090709 at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 20 dot 1605052236310 dot 24016 at digraph dot polyomino dot org dot uk> <572CD397 dot 2090405 at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 20 dot 1605062118090 dot 15027 at digraph dot polyomino dot org dot uk> <c6fdca14-2c5a-4b9a-8dd9-25630c6a100e at linux dot vnet dot ibm dot com> <14407237-8cae-2c6f-118e-7db707cc61af at linux dot vnet dot ibm dot com>
On Fri, 10 Jun 2016, Paul E. Murphy wrote:
> Implementation support for the ISO C11 7.12.3
> classification macros:
>
> __finiteF
> __fpclassifyF
> __isinfF
> __isnanF
> __issignalingF
> __signbitF
Noting that, if we add support for _FloatN / _FloatNx APIs in future in
cases where those types are ABI-compatible with another type that already
has such __* functions, exported aliases are *not* added for those
internal functions. For example, if a platform where long double is
binary128 gains *f128 API support, then the public functions would get
public *f128 aliases (so they can be used without including system
headers, as allowed by ISO C), but there would be no __finitef128 alias,
etc. (and the same would apply to __*_finite in that case). (Cf. how in
the case where long double = double, such functions only have *l aliases
as compat symbols if LDBL_CLASSIFY_COMPAT because they were unnecessarily
exported on some platforms but new platforms should not have those
aliases.)
> Likewise, through libm via complex.h:
>
> cbrtF
> ceilF
These are math.h functions, not complex.h functions.
> Macros needing altered in math.h:
> signbit
Remark on signbit: in GCC 6, __builtin_signbit is type-generic and works
with sNaNs. So with GCC 6, you don't actually need __signbitF backing
functions. But (a) there would still need to be a new __GNUC_PREREQ (6,
0) definition of signbit in math.h using type-generic __builtin_signbit
and (b) __signbitF might still be relevant for working with any non-GNU
compilers without type-generic __builtin_signbit but with __float128
support.
> [8] Does this imply a case whereby __STDC_WANT_IEC_60559_TYPES_EXT__ is
> defined, but not __STDC_WANT_IEC_60559_BFP_EXT__ within tgmath.h which
> would result in next{up,down}F being declared but not
> next{up,down}{f,,l} when using the next{up,down} macros?
If __STDC_WANT_IEC_60559_BFP_EXT__ is not defined, <tgmath.h> does not
define nextup and nextdown macros at all. See where TS 18661-1 says
"After 7.25#1, insert the paragraph: [1a] The following identifiers are
defined as type-generic macros only if __STDC_WANT_IEC_60559_BFP_EXT__ is
defined as a macro at the point in the source file where <tgmath.h> is
first included:". TS 18661-2 modifies this to define some of those macros
also if __STDC_WANT_IEC_60559_DFP_EXT__ is defined, but that's not
relevant to glibc; TS 18661-3 does not modify it further, so if you define
__STDC_WANT_IEC_60559_TYPES_EXT__ but neither
__STDC_WANT_IEC_60559_BFP_EXT__ nor __STDC_WANT_IEC_60559_DFP_EXT__ then
you get nextup for the new types but not the old ones, and no nextup
type-generic macro.
--
Joseph S. Myers
joseph@codesourcery.com