bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: glibc 2.2: math test failures


From: Michael Deutschmann
Subject: Re: glibc 2.2: math test failures
Date: Mon, 30 Apr 2001 00:58:30 -0700 (PDT)

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.

> 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*.

---- Michael Deutschmann <address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]