IEEE issues with GCC on x86-linux

IEEE issues with GCC on x86-linux

[Jochen Küpper]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

I am trying to run the GSL test-suite with GSL_IEEE_MODE set.

The system is GNU/Linux 2.6.4-52-smp, gcc-3.3.3, gsl-1.5.90
(cvs-HEAD). Compile-flags used are
,----[CFLAGS]
| -g -mcpu=i686 -pipe -O2 -Wall -mfpmath=sse -mieee-fp
`----

When I run the test-suite with GSL_IEEE_MODE being undefined all tests
pass. However, when I try to set GSL_IEEE_MODE it has to include
`mask-all', otherwise some tests fail. 

Specifically sys/test.c fails at line 332 when using the following
mode:
,----[GSL_IEEE_MODE]
| double-precision,round-to-nearest,mask-underflow,mask-denormalized
`----

,----[gdb output]
| Program received signal SIGFPE, Arithmetic exception.
| 0x4003c306 in __ieee754_exp () from /lib/tls/libm.so.6
| (gdb) bt
| #0  0x4003c306 in __ieee754_exp () from /lib/tls/libm.so.6
| #1  0x4003fda0 in exp () from /lib/tls/libm.so.6
| #2  0x08049bab in main () at ../../sys/test.c:332
`----

,----[test.c:332]
|     inf = exp (1.0e10);
`----

Is this expected? Any hints are appreciated.

Greetings,
Jochen
-- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Liberté, Égalité, Fraternité                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: IEEE issues with GCC on x86-linux

[Brian Gough]

Jochen Küpper writes:
 > ,----[test.c:332]
 > |     inf = exp (1.0e10);
 > `----
 > 
 > Is this expected? Any hints are appreciated.

That is expected, because the program is testing Inf/Nan and I wanted
to generate an infinity from an actual computation.  For the tests I
use mask-all.

If you would like to make the tests work without it, you could do
something like this,

#ifdef INFINITY
  inf = INFINITY;
#else
  int = exp(1.0e10);
#endif

(Similarly for NAN). This assumes that macro definitions are actually
valid....  but check ahead and see if there are other tests ( in other
directories) which generate floating point exceptions (I think there
are some in specfunc/, but maybe they can be eliminated easily).  It
would only make sense to start changing these if the whole test suite
can be tidied up to avoid them.

-- 
Brian Gough