Ping Re: Fix IBM long double spurious overflows
Joseph S. Myers
Tue Jan 28 21:20:00 GMT 2014
On Tue, 28 Jan 2014, David Edelsohn wrote:
> 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
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
More information about the Gcc-patches