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: Steven Munroe <munroesj at linux dot vnet dot ibm 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, 7 Jun 2016 22:30:31 +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> <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> <1465336580 dot 18737 dot 42 dot camel at oc7878010663>
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