On Tue, 28 Jan 2014, David Edelsohn wrote: > On Tue, Jan 28, 2014 at 4:19 PM, Joseph S. Myers > <jos...@codesourcery.com> 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 jos...@codesourcery.com
