This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Minimum floating-point requirements
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Steve Munroe <sjmunroe at us dot ibm dot com>
- Cc: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, David Edelsohn <dje dot gcc at gmail dot com>, <libc-alpha at sourceware dot org>
- Date: Mon, 10 Feb 2014 23:03:28 +0000
- Subject: Re: Minimum floating-point requirements
- Authentication-results: sourceware.org; auth=none
- References: <CAGWvnym4yN=7rLrm0RRtNN++T=xwx8r3MUKJOfz4r+H=Z9zd7Q at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1401300038120 dot 24633 at digraph dot polyomino dot org dot uk> <OF9FA4A0A3 dot 0CD33B43-ON86257C70 dot 0073531F-86257C70 dot 0073A4BB at us dot ibm dot com> <Pine dot LNX dot 4 dot 64 dot 1401302108080 dot 12540 at digraph dot polyomino dot org dot uk> <Pine dot LNX dot 4 dot 64 dot 1402072347200 dot 12232 at digraph dot polyomino dot org dot uk> <OF54854818 dot C108092B-ON86257C7B dot 0063B8C0-86257C7B dot 006B6B53 at us dot ibm dot com>
On Mon, 10 Feb 2014, Steve Munroe wrote:
> I disagree with trying make IBM Double Double comply with of all the
> corners of IEEE. We never claimed that it was or ever would be compliant
> with IEEE. Last I checked, X86 long double (x87 __binary80) is not IEEE
> either.
x87 long double follows IEEE semantics for operations and exceptions,
meaning it is not problematic in the same way as IBM long double.
My aim is simply that the foundations on which glibc is built are reliable
enough to do so. This means, in my view, that the arithmetic should
follow at least the standards applied to miscellaneous glibc libm
functions (and documented in the glibc manual in 2.19) - not all the
corners of IEEE, but a rather more basic standard for C arithmetic
semantics.
> Also I don't see any reason to move the double double implementation from
> libgcc to GLIBC. GLIBC/libm is already statically linking to libgcc_s so
> there where be no performance benefit to moving the source into GLIBC.
It's not about performance, it's about being a reliable enough basis for
generic floating-point code in glibc to work. If libgcc can't provide
that basis, that means putting a copy of the code in glibc.
> So this seems to come down a abstract discussion about correctness and IEEE
> compliance. IBM double double only supports round to even mode. Trying to
glibc is an implementation of the standard C library, for which the
semantics do not admit of floating point types that only support round to
even mode when fesetround succeeds for other modes (i.e., types producing
invalid results for operations or library functions if called in other
modes).
"only supports round to even mode" is consistent with C if it means
"produces results that are valid numbers and reasonable approximations to
correct results, but not correctly rounded in a way respecting the
rounding direction". It is not if it means "produces invalid results in
other rounding modes". My proposal is to change from the latter to the
former (given appropriate command-line options).
This is not an abstract discussion, it is about maintainability of glibc,
where large blocks of long-term expected failures resulting from defects
outside of glibc cause trouble for people attempting to fix issues
globally for all platforms where they appear (as is the preferred norm for
any fix in glibc) or more generally working with the libm testsuite (and
form unwanted noise even for people testing on other platforms).
I don't want to keep having to go through large amounts of noise on
powerpc when fixing some libm problem (globally) after improving test
coverage, or every release cycle when seeking to ensure the test results
for soft-float powerpc are clean and problems shown up by test results are
fixed; I want to fix the causes of these problems at their source, once
and for all.
> make it behave "correctly", in other rounding modes can only slow it down
> and cause collateral bugs to ripple through the infrastructure. Adding
> extra symbols for the non-default rounding mode seems like a lot of work,
> that in the end may not solve the original problem.
It seems pretty simple to me (and clearly better than forking a copy of
the code for glibc).
> It would be better to work on enabling IEEE __float128 (in vector
> registers) as a parallel option, then when all the infrastructure is in
> place, provide an option to switch application long double over that to
> that.
I am doubtful that doing this for the three long-standing ABIs (32-bit
hard float, 32-bit soft float, 64-bit BE) - bearing in mind that many
32-bit processors may not have the vector registers - would be
particularly helpful to glibc users, but if the users and GNU/Linux
distributors are willing to move to new and incompatible ABIs, as they
moved from ARM old-ABI to EABI, and so obsolete IBM long double
completely, then that would certainly help.
--
Joseph S. Myers
joseph@codesourcery.com