Re: Adding __float128 (i.e TS 18661-3)

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

On Tue, 2016-06-07 at 21:21 +0000, Joseph Myers wrote:
> On Tue, 7 Jun 2016, Steven Munroe wrote:
> 
> > Yes it seems that _Float64x are specifically defined to enclusively
> > cover x86 80-bit and seems to exclude the IBM long double.
> 
> (And in fact it excludes the m68k variant of ldbl-96 as well, because of 
> the required relation between minimum and maximum exponents, although 
> otherwise the values of that type follow IEEE semantics.)
> 
> > I assume that you object to using a standard "extented" type in a none
> > standard way.
> > 
> > How about using an "extendable" type unique to IBM long double.
> 
> That's not what's meant by "extendable" in IEEE 754.  Extendable means 
> something like _Float<113, 16383> with IEEE semantics but user control 
> over precision and range.  None of the parts of TS 18661 will include any 
> support for extendable formats.  I don't envisage any support for such 
> formats in GCC or glibc.
> 
I was thinking primarily of the internals of glibc.

I was not suggesting this would fit under TS 18661 or IEC 60559 or be a
public API. But the mechanics of concurrently building both 128-bit
types are simplified with it.

We will also need alternative (to 'l') file suffixes that we can alias
to for verioning of the old (IBM) long double API.

> > Thankfully Mike Meissner enable both __float128 and __ibm128 in GCC-6.1:
> > https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/Floating-Types.html#Floating-Types
> > 
> > 
> > Is this acceptable?
> 
> I don't see a need for explicit APIs (i.e., new function, constant etc. 
> names) for __ibm128.  Functions for __ibm128 can be accessed by using 
> "long double" with -mabi=ibmlongdouble (or whatever option is supported 
> for selecting that long double choice) or with a compiler where that is 
> the default.  Functions for __float128 can be accessed both with the 
> explicit *f128 names associated with that type, and with "long double" for 
> a compiler using -mabi=ieeelongdouble or where that is the default (once 
> the support is added for __float128 as long double, that is, which will be 
> a separate series of changes after the support for *f128 APIs is done).
> 
My concern is this may work for source files for compile but is awkward
at best for externs and inlined in header files. Either would be
extremely fragile. 

I also have to think about other projects beyond glibc (like boost).

Having a explicit type that always maps to TFmode and another type that
always maps to KFmode simplify things immensely. 


> (Of course, the __ibm128 type name might be used internally where 
> necessary in glibc in the implementation of code handling both types.  
> E.g., the implementation of type-generic macros such as isinf, in the 
> cases where it ends up calling a function, would need to know that 
> __ibm128 uses __isinfl while __float128 uses __isinff128, and might well 
> use both those type names explicitly.  There's an open question of the 
> extent to which type-generic macros should support __ibm128 in the case 
> where it's not long double.)
>