Re: [PATCH 4/6] ldbl-128: Rename 'long double' to 'ldouble_t'

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 16 Aug 2016, Paul E. Murphy wrote:

> > I think the right name to use is _Float128; that name unambiguously 
> > relates to the format these functions are written for.  (When we can 
> > assume a compiler with _FloatN / _FloatNx support, the ideal would be that 
> > these functions always define the associated _Float128 function names, use 
> > *f128 constants directly, etc., and may or may not, depending on the glibc 
> > configuration, also have aliases with the long double names, with 
> > _Float64x names or with both sets of names.  This series is of course only 
> > achieving an interim step towards such a goal which isn't possible yet, 
> > but there should be no problem using the _Float128 name for the macro 
> > now.)
> 
> That was my original thought, but it begs the question of why the
> implementation should reside in ldbl-128 folder.

My answer is that ideally it wouldn't; see the sort of directory structure 
I suggested in 
<https://sourceware.org/ml/libc-alpha/2016-05/msg00092.html>.  But that's 
what things would look like ideally, eventually, not something necessarily 
required to achieve support for _Float128 as an additional type.

> Likewise, other long double formats do include some ldbl-128 files
> with the intent of building them using the native long double format
> (e.g ldbl-128ibm e_j0l.c).  Thus, calling such a macro _Float128 is
> misleading, or wrong, in those circumstances.

And maybe just those few files, written for this format but also used for 
ldbl-128ibm, would use another layer of indirection for their types.  
_Float128 is logically correct for the vast bulk of the ldbl-128 
functions.

(Strictly, of course, _Float128 is a separate type from long double on 
platforms where they have the same representation.  Juggling the types and 
function names to avoid issues declaring a long double function with the 
wrong type is something that would need to be done by whoever adds support 
for *f128 aliases for *l functions on such platforms, but that's not part 
of what you need to do here.)

> >> diff --git a/sysdeps/generic/math_private.h b/sysdeps/generic/math_private.h
> >> index 08b04e0..15f1efc 100644
> >> --- a/sysdeps/generic/math_private.h
> >> +++ b/sysdeps/generic/math_private.h
> >> @@ -185,6 +185,13 @@ do {								\
> >>     ldbl-128 files as another type (e.g _Float128).  */
> >>  #define mathx_hidden_def(name) hidden_def(name)
> >>  
> >> +/* These hooks let us override certain long double files using
> >> +   a different type (e.g building ldbl-128 as _Float128).  */
> >> +#ifndef __LDOUBLE_T_OVERRIDDEN
> >> +# define ldouble_t long double
> >> +# define L(x) x##L
> >> +#endif
> > 
> > I don't think this header is the right place for something entirely 
> > specific to the ldbl-128 function implementations.
> 
> Ultimately, this will be needed to build the ldbl-128ibm under whatever
> typename emerges when transitioning the ppc64le long double format.

I don't see that as needed (in a generic header, anyway; no doubt 
something will be needed in a header specific to ldbl-128ibm).  
ldbl-128ibm could always be built with an appropriate -mabi option to 
select IBM long double, or using __ibm128 and any constant suffix you add 
for the purpose.

-- 
Joseph S. Myers
joseph@codesourcery.com