This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Adding __float128 (i.e TS 18661-3)
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Steve Munroe <sjmunroe at us dot ibm dot com>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>
- Date: Tue, 07 Jun 2016 16:56:20 -0500
- Subject: Re: Adding __float128 (i.e TS 18661-3)
- Authentication-results: sourceware.org; auth=none
- References: <572BB6DF dot 7090709 at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 20 dot 1605052236310 dot 24016 at digraph dot polyomino dot org dot uk> <1465331531 dot 18737 dot 28 dot camel at oc7878010663> <alpine dot DEB dot 2 dot 20 dot 1606072103460 dot 9812 at digraph dot polyomino dot org dot uk>
- Reply-to: 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.)
>