Ping Re: Fix IBM long double spurious overflows

Joseph S. Myers
Wed Jan 29 03:18:00 GMT 2014

On Tue, 28 Jan 2014, David Edelsohn wrote:

> On Tue, Jan 28, 2014 at 4:19 PM, Joseph S. Myers
> <> wrote:
> > The glibc libm testsuite has much more thorough coverage (hopefully soon
> > to include running all tests in all rounding modes by default) than it did
> > two years ago, and it's a pain to keep test results clean across all
> > architectures when the basic arithmetic operations for IBM long double do
> > not follow the normal conventions as regards permitted errors for most
> > glibc libm functions (results within a few ulps, no spurious overflows or
> > underflows except possibly for exact underflowing results, no missing
> > underflows), or as regards working in all rounding modes, making it hard
> > to distinguish between libgcc and glibc bugs.
> >
> > Thus, if these issues are not to be fixed in libgcc, I think we need to
> > seek FSF approval to use a copy of the current IBM long double libgcc code
> > under LGPLv2.1+ in glibc, with a view to fixing the issues in that copy
> > only and linking it directly into libc and libm (for their internal use
> > rather than re-exporting symbols from it).
> Joseph,
> The testsuite can disable those tests or xfail them for IBM long double.

Doing so requires significant investigation for each test to determine 
that it arises from a libgcc bug.  For tests in auto-libm-test-in it is 
also liable to disable more than necessary, because each source line 
represents tests with the specified inputs rounded up and down for each 
supported floating-point format - disabling tests like this was never 
intended to be permanent, only a temporary marking until the underlying 
bug is fixed.

> It is not appropriate for a GCC or GLIBC maintainer to impose behavior
> or conformance on a specific target and port-specific code. I am sorry
> that the failures bother you, but ports have the freedom to conform or
> not conform with standards in target-specific code.

It is appropriate for glibc maintainers to seek consensus in the glibc 
community on minimum requirements for glibc ports, just as on any other 
question about what is or is not supported in glibc.  For example, it is 
presently expected that a port uses ELF and supports TLS and PIC.  What 
floating-point formats are supported is part of that.

I'll seek consensus in the glibc community on minimum standards for the 
underlying floating-point arithmetic.

Note that some architectures use -mieee when building glibc in order to 
get floating point corresponding to glibc expectations (which may be 
slower than the GCC defaults on those architectures).

Joseph S. Myers

More information about the Gcc-patches mailing list