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: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat 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: Mon, 9 May 2016 14:52:26 +0000
- 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> <alpine dot DEB dot 2 dot 20 dot 1605052352260 dot 24016 at digraph dot polyomino dot org dot uk> <57309976 dot 2040705 at redhat dot com>
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