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 22:30 +0000, Joseph Myers wrote:
> On Tue, 7 Jun 2016, Steven Munroe wrote:
> 
> > We will also need alternative (to 'l') file suffixes that we can alias
> > to for verioning of the old (IBM) long double API.
> 
> Given that the *l symbols will be for the old API and *f128 symbols for 
> the new API (possibly with __*f128 as well for namespace reasons), one 
> approach might well be to keep the *l suffixes for the IBM long double 
> files.  (This is speculation rather than a definitive design.)
> 
> > Having a explicit type that always maps to TFmode and another type that
> > always maps to KFmode simplify things immensely. 
> 
> Well, you have those types, and you have the ABIs (functions exported from 
> libraries) - the question is about corresponding APIs.
> 
> For printf/scanf/strfmon-like functions, there are no format strings 
> explicitly associated with __ibm128 or __float128, and no APIs explicitly 
> associated with a particular choice of long double (in line with the 
> choice made in TS 18661 about using strto/strfrom functions) - building 
> with the desired choice of long double is the only option.  (There are 
> already separate ABIs for these functions for long double = double, except 
> for those I identified as having been missed there.)
> 
Again I am primarily concerned with internal glibc interfaces (like
where libm functions internally call other libm functions.

Obviously we have to insure that the __ibm128 functions can call the
appropriate internal API for supporting __ibm128 functions. And the
__float128 functions can call the appropriate internal API for
__float128.

And we would like to avoid compile errors due to missing compiler
options and associated type randomization.

Separately we do use the printf plugin API to support _Decimal Float and
vector printf and provide these to Linux on Power customers. It is fair
to assume that we would provide a 'Q' format plugin for early adopters
of __float128. 

While this does not directly involve glibc, having both types and a
common naming structure is helpful. Here I am looking at a larger
context then glibc and the emerging standards.

> For other functions, where long double is part of the prototype, we have I 
> think consensus on adding explicit __float128 variant APIs for 
> non-obsolescent functions (subject to getting detailed consensus on the 
> exact list).  I don't think we have consensus on such an API set for 
> __ibm128.  A large set of platform-specific APIs like that would be very 
> different from any other API sets added to glibc and so would need 
> particularly careful consideration by the community.  (Although since such 
> APIs wouldn't need extra ABIs, it would be possible for a header outside 
> of glibc to provide them for anything that needs them - it just needs a 
> series of declarations like "__ibm128 sinibm128 (__ibm128) __asm__ 
> ("sinl");", to map those APIs to existing entry points.)
> 
> I haven't considered the details of what e.g. libstdc++ support should 
> look like at the implementation level, but the high level idea of what 
> full libstdc++ support for a type should provide the user is 
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622>.
>