This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 4/8] float128: Add public _Float128 declarations to libm.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Gabriel F. T. Gomes" <gftg at linux dot vnet dot ibm dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Tue, 2 May 2017 21:40:27 +0000
- Subject: Re: [PATCH v2 4/8] float128: Add public _Float128 declarations to libm.
- Authentication-results: sourceware.org; auth=none
- References: <1493415280-30534-1-git-send-email-gftg@linux.vnet.ibm.com> <1493415280-30534-5-git-send-email-gftg@linux.vnet.ibm.com> <alpine.DEB.2.20.1704282218540.16448@digraph.polyomino.org.uk> <20170502175300.44336b5a@keller.br.ibm.com>
On Tue, 2 May 2017, Gabriel F. T. Gomes wrote:
> > (a) Does the compiler support a particular type name (such as _Float128)?
> >
> > (b) Does the compiler support some name for a type that is ABI-compatible
> > with _Float128 (the name possibly being __float128 or long double)?
>
> Actually, we've been using __HAVE_FLOAT128 as ((a) || (b)) and the
> comments aren't helping.
(a) implies (b) as I'm interpreting it (_Float128 being a possible name
for such a type), so that's just (b), which isn't actually something I
think the headers need - anything conditional in the headers should be
conditional on library support also being present (after all, e.g. AArch64
has such a type - long double, and _Float128 in GCC 7, but shouldn't
enable the declarations until the relevant aliases are present in the
library).
> What about this:
>
> /* Defined if the current compiler invocation provides a 128-bit
> floating point type compatible with IEEE 754. */
> #define __HAVE_FLOAT128 0
I'd suggest
/* Defined to 1 if the current compiler invocation provides a
floating-point type with the IEEE 754 binary128 format, and this glibc
includes corresponding *f128 interfaces for it. */
#define __HAVE_FLOAT128 0
/* Defined to 1 if __HAVE_FLOAT128 is 1 and the type is ABI-distinct
from the default float, double and long double types in this glibc. */
#define __HAVE_DISTINCT_FLOAT128 0
(Note the "default" in the comment on __HAVE_DISTINCT_FLOAT128 - I'm
referring to the functions that get the symbols with the C11 *f, *, *l
names. If in future you support binary128 long double for powerpc64le,
with *l API calls mapped to __*f128 ABI calls, it's still ABI-distinct
from default long double in that sense, meaning that e.g. __isinff128
needs to be declared, __isinfl is for ibm128 and __isinff128 is for
float128 whatever the C names for those types.)
> > (c) Does this glibc build include support for _Float128 (that is, *f128
> > functions / aliases, and all the associated header pieces)? If
> > ABI-distinct, the headers *should* care about this even when the functions
> > aren't going to be declared, because of the type-generic <math.h> macros
> > that might need to call __isinff128 etc.
>
> We don't have a macro that indicates that support for _Float128 is
> provided in our glibc builds. This information is currently implicit.
>
> We now understand that this is useful for glibc users. Do you have any
> suggestion for the macro name?
I'm suggesting the above macros as being only for use in other glibc
headers, not for users. Users wanting to test for support can do e.g.
"#ifdef HUGE_VAL_F128".
> > (e) Should this compilation expose declarations for the *f128 interfaces?
> > I think it's best for this to be represented as ((b) && (c)) &&
> > __GLIBC_USE (IEC_60559_TYPES_EXT), rather than having its own macro.
> >
> > It looks rather like you're using __USE_FLOAT128 as (e), which as noted I
> > don't think should have its own macro at all,
>
> We decided to provide this macro to avoid having to write all the
> condition multiple times in the code. We could change this, but is it
> the best thing to do?
The __GLIBC_USE macro gets recomputed for each header included, to reflect
that what matters for __STDC_WANT_IEC_60559_TYPES_EXT__ is its value when
an affected header is included - not when some unrelated system header is
included.
I'd say that if any macro represents __HAVE_FLOAT128 && __GLIBC_USE
(IEC_60559_TYPES_EXT), you need to be very careful about ordering, so that
it also reflects the current value of __GLIBC_USE (IEC_60559_TYPES_EXT).
It's true that CFP DR#3 says the __STDC_WANT_* macros must be defined or
undefined the same for all affected headers. But bits/floatn.h also needs
to be included by some headers that aren't listed in TS 18661-3 as being
affected by __STDC_WANT_IEC_60559_TYPES_EXT__: wchar.h needs to include
it, and then declare wcstof128 if __HAVE_FLOAT128 && defined __USE_GNU.
Since it's legitimate to do
#include <wchar.h>
#define __STDC_WANT_IEC_60559_TYPES_EXT__
#include <math.h>
(for example), you'd need to make sure that math.h gets the correct value
of any combined macro. I think it's simpler just to use
#if __HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT)
where needed. Or have a macro __GLIBC_USE_FLOAT (128) which is defined as
#define __GLIBC_USE_FLOAT(N) __HAVE_FLOAT ## N && __GLIBC_USE (IEC_60559_TYPES_EXT)
so that it automatically reflects the current value of __GLIBC_USE
(IEC_60559_TYPES_EXT).
Also, another point on conditions under which to declare functions: all
the TS 18661-1 functions should be declared for the new type if
__HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT), whether or not
__GLIBC_USE (IEC_60559_BFP_EXT) is true. So all the
#if __GLIBC_USE (IEC_60559_BFP_EXT)
conditionals in bits/mathcalls.h need to be changed to
#if __GLIBC_USE (IEC_60559_BFP_EXT) || defined __FLOATN_TYPE
or similar. (See what I said about this in
<https://sourceware.org/ml/libc-alpha/2017-01/msg00333.html>.)
Also, you're missing the SNANF128 macro.
--
Joseph S. Myers
joseph@codesourcery.com