This is the mail archive of the 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: Adding __float128 (i.e TS 18661-3)

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.

> Thankfully Mike Meissner enable both __float128 and __ibm128 in GCC-6.1:
> 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).

(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.)

Joseph S. Myers

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