Re: glibc 2.2: math test failures

[Michael Deutschmann]

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>