Ping Re: Fix IBM long double spurious overflows

Joseph S. Myers joseph@codesourcery.com
Tue Jan 28 21:20:00 GMT 2014


On Tue, 28 Jan 2014, David Edelsohn wrote:

> Joseph,
> 
> Adding the various tests for overflow slows down some other code where
> performance is important.  Explicitly changing rounding mode would be
> even more invasive and have significant performance impact.
> 
> This long double format never was designed for the rounding features
> of the current ISO C standard. The format has been used effectively
> without the additional features and there have not been requests for
> conformance from normal users of the long double format.
> 
> Without a clearer need, there is no urgency to make the format fully
> conforming and implement all of the performance mitigation and
> alternatives. We prefer to not pursue the fixes until circumstances
> change.

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 S. Myers
joseph@codesourcery.com



More information about the Gcc-patches mailing list