[Top][All Lists]
[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: |
Tue, 12 Dec 2000 21:07:33 -0800 (PST) |
On 10 Dec 2000, you wrote:
> Michael Deutschmann <address@hidden> writes:
>
> > So I decided to try running make check with the oldest and slowest
> > computer I own -- a 16MHz 80386 with a Weitek coprocessor. Needless
> > to say, this took awhile...
>
> Well, I'll not address this. These kind of machines are simply
> obsolete and adjusting the expected errors only means that we miss
> other errors on better hardware.
You mean you can adjust them? I'd have thought that those tests were to
check if the library conforms to external standards as to the behavior of
these functions. So "fixing" the test would mean retracting a claim as
to the accuracy of the library, or rewriting the library function not to
use problematic FPU instructions (with severe speed penalties).
BTW, I was wrong about the coprocessor -- it wasn't a Weitek (which
probably wouldn't have been recognized as an FPU by Linux at all) -- it's
an IIT 3C87SX. Documentation on "chiplist" (a FAQ-like document associated
with comp.sys.ibm.pc.hardware.chips) says of it:
) 3.13 IIT IIT-3C87 NPX
)
)NPX for Intel i80386 CPU.
)
)Not fully Intel i80387 NPX instruction compatible.
)Extra features.
So this indicates these problems probably do not apply to a genuine
80386/80387 system. (However, I don't have such a computer to verify this.)
It seems the answer is for you to "blacklist" the chip -- add an entry to
the FAQ like so:
4.xx. I get many math-related test failures on my old 386.
This is probably a hardware failure, of a sort. 80386 systems
rely on an additional math coprocessor chip (80387) to handle
floating point operations.
A few 386 systems have coprocessors that are not 100% compatible
with the Intel 80387, such as the IIT 3C87. Some may violate
the IEEE 754 accuracy standards in ways glibc is not prepared to
compensate for.
So, glibc running on such a system does not support math
correctly, and the tests tell you this. That said, most users
probably will not notice the difference.
Please do not report these failures as bugs in glibc. Few 386s
are still in service these days, and it's not possible to
compensate for this without performance penalties for more
modern systems.
(Note I don't really know what I'm talking about wrt. the IEEE
standards. Hope I got it right, above.)
---- Michael Deutschmann <address@hidden>