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

["Gabriel F. T. Gomes" <gftg at linux dot vnet dot ibm dot com>]

On Tue, 2 May 2017 21:40:27 +0000
Joseph Myers <joseph@codesourcery.com> wrote:

> 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".

Let me confirm that I understood this correctly...

On the one hand, the macros __HAVE_FLOAT128 (meaning ((b) && (c))) and
__HAVE_DISTINCT_FLOAT128 (meaning ((b) &&(d))) are not to be tested by
the users, explicitly.  On the other hand, these macros are to be
present in the installed header (floatn.h), so that, when a user
includes math.h, the user will get the declarations for *f128 functions
(if __HAVE_FLOAT128 = 1) and will indirectly access __*f128 functions
(e.g. __isinff128) through __MATH_TG macros (if
__HAVE_DISTINCT_FLOAT128 = 1).

Or are you implying that the macros __HAVE_FLOAT128 and
__HAVE_DISTINCT_FLOAT128 should not be visible at all by users (i.e.
should not be in an installed header)?