Adding __float128 (i.e TS 18661-3)

[Joseph Myers]

On Mon, 9 May 2016, Florian Weimer wrote:

> I assume it is used to implement a C version of C++ function templates such as
> 
>   template <class LongDoubleType> int
>   vfprintf (FILE *s, const CHAR_T *format, va_list ap);

printf/scanf/strfmon-like functions are not part of the present proposal.  
They would need to be added for any subsequent changes that add the option 
for long double being binary128 on powerpc64le.  But the present proposal 
is only about explicit interfaces for binary128.  And since TS 18661-3 
does not have explicit-binary128 variants of printf/scanf, the present 
proposal doesn't either.  (Rather, one preparatory change would add the 
strfrom* functions from TS 18661-1 for the existing floating-point types, 
while later changes would add functions such as strtof128 and strfrom128 
(and ones such as wcstof128 corresponding to wcstold and strtof128_l, 
etc., to be listed in detail as part of the proposal).)

(Similarly, adding a new long double type would mean adding additional 
copies of obsolescent functions such as qecvt and scalbl to handle the new 
type - since those functions are part of the glibc API, supported for new 
links - but those should not get versions that explicitly take float128 
arguments because of their obsolescent nature.)

> with a matching LongDoubleType argument.  But I don't know how it works in
> detail, and how unintended spillover between different copies is prevented.
> (C++ has name mangling for that.)

The existing support for long double being either binary64 or ibm128, on 
powerpc, or either binary64 or binary128, on some other platforms where 
the format changed in the past, involves the wrappers for long double = 
double setting a TLS variable __no_long_double (see 
sysdeps/ieee754/ldbl-opt/nldbl-compat.c).

This has obvious problems, in that it adds to the cases when functions 
such as dprintf are not AS-safe when we'd like them to be AS-safe unless 
dynamic allocation is needed.  It may not be a good design for adding a 
third long double variant.  But it doesn't need addressing for the present 
proposal.

It is *also* the case that, as I previously noted, the 2004-6 changes 
appear to have missed out such compatibility support for the printf-like 
functions in argp.h, err.h and error.h.  A lot of care will be needed to 
make sure the *complete* set of relevant functions is handled in any 
future support for a third long double type.  Again, something for 
followup changes dealing with different long double types, not now.

-- 
Joseph S. Myers
joseph@codesourcery.com