This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2 4/8] float128: Add public _Float128 declarations to libm.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]