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 jos...@codesourcery.com
