This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How do we test the IBM ieee754 math library?


> Date: Sun, 25 Nov 2001 08:46:45 -0500 (EST)
> From: Stephen L Moshier <moshier@mediaone.net>
> Reply-To: moshier@moshier.ne.mediaone.net
> cc: libc-alpha@sourceware.cygnus.com
> 
> 
> > Have you compared the IBM libm on x86 against the asm version on x86?
> > How are the results of "make check" in glibc?
> 
> What I checked, more specifically, was IBM libm functions running with the
> x86 coprocessor set to double precision.  Now I see that using the
> default linux fpu setting of 80-bit long double mode, the IBM routines
> totally fall to pieces.

This is not surprising.  The previous libm didn't support that mode
either.  You'd basically have to rewrite all the routines for the
non-IEEE arithmetic of GCC in this mode.

> On x86 linux, make check doesn't run very far without coaxing.
> It reports things like
>     atest-exp.out:
>     131049 failures; 0 errors; error rate 0.00%
>     maximum error:   0b7f0f5245eea089d210d002d3fb98d57
>     error in exp(1): 00000000000000000000000cbffc1f5e9
> 
> This may not be worthwhile trying to fix except to ask what
> computer these programs were developed on or what computers they have
> actually been tested on.  Evidently the code is intolerant of IEEE
> flaws so there are going to be various systems on which it dosn't work
> properly.

Well, not that many.  Powerpc, sparc, ia64, hppa, and alpha should all
be fine, as should any target that uses soft-float; all those are
strict IEEE.  I think s/390 is also strict IEEE.  That leaves m68k,
which I understand is also OK for IEEE arithmetic, and x86.

The x86 rounding problems are really very severe for this kind of
numeric code.  The normal thing you see with 'nearly IEEE' arithmetic
is lack of denormals, lack of exceptions, and only round-to-nearest
mode, all of which only affect extreme cases.  I think GCC on x86 is
one of a very few commonly-used platforms where you can add two
numbers and get a less accurate result than what IEEE specifies.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]