Re: glibc 2.2: math test failures

[Andreas Jaeger]

Michael Deutschmann <address@hidden> writes:

> On 30 Apr 2001, you wrote:
> > Michael Deutschmann <address@hidden> writes:
> > 
> > > > > 2.2.1 is not yet releases.  Once it is I meant.
> > > 
> > > Seems I was distracted by other things at the time 2.2.1 and even 2.2.2 
> > > was
> > > released.  But I've finally gotten around to recompiling and retesting.
> > 
> > I don't remember your exact bug report.
> 
> It was that glibc-2.2.0 was giving me math test failures on a DX4,
> apparently due to the 486 npu being less precise than that of later IA-32
> processors.  I was following up to report that it has been fixed for me in
> 2.2.2.
> 
> I also reported even worse problems on an old 386 with an IIT coprocessor,
> but Ulrich declared that's too old to be worth fixing.
> 
> > > The math errors are gone (or at least suppressed).  However, the test 
> > > failures related to Linux 2.2 features (LFS and one AIO test) still 
> > > continue.  You should suppress these tests on Linux 2.0 systems, or at 
> > > least mentioned it in your FAQ.  (I haven't retested the 386).
> > 
> > I don't see those failures with Linux 2.2 in glibc 2.2.3.  Which
> > version did you test?  If it still fails, please send some more
> > details, we tried to fix the failing tests.
> 
> No, I meant that the tests presuppose Linux 2.2 features, so if I run
> "make check" on Linux *2.0*, these two tests always fail, as 2.0 does not
> support LFS or "realtime" signals above 32.

I see.  If it still fails for you in 2.2.3, please send a patch to fix
it.  The glibc developers don't use such an old kernel and therefore
can't test it themselves - and no, we're not going to add a test "if
this is Linux 2.0,..." but checks for ENOSYS tests are fine.

> > There's no general rule.
> 
> That is a problem.  The "known errors" manual page is not very useful, 
> since (as it acknowledges), it's possible for even worse errors to 
> exist.  Since there's no guarantee that the discovery of a worse error 
> will result in anything else than a revision in said page, it's not very 
> useful.  Someone who is writing numeric software would want instead a 
> list of error bounds that may be wider but will be *defended*.

That's the aim of all of this.  With 2.2.3 we have for the first time
some functions that are bit accurate.  If we have more such functions
we'll write this but at the moment it's useless since there're not
enough numeric experts to help glibc.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs address@hidden
   private address@hidden
    http://www.suse.de/~aj