Adding __float128 (i.e TS 18661-3)

[Joseph Myers]

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

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

-- 
Joseph S. Myers
joseph@codesourcery.com