Minimum floating-point requirements

[Joseph S. Myers]

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