#44 Floating Point Exception Handling Prob.

[Anonymous]

Symptom:

Floating point divide test fails (/ 1 0.0) by terminating execution altogether due to
unhandled/unmasked floating point exception.

In module spvw.d, there appears to be code to set this up:

#if defined(UNIX_LINUX) && (defined(FAST_FLOAT) || defined(FAST_DOUBLE)) &&
!defined(HAVE_FPU_CONTROL_T) && defined(HAVE_SETFPUCW)
# Damit Division durch 0.0 ein NaN und kein SIGFPE liefert.
__setfpucw(_FPU_IEEE);

This appears to be a obsolete i386 call, which would understandably never be invoked on our
linux/ppc hardware. However, the other thing that is supposed to deal with fp exceptions also
doesn't work. From unixaux.[cd], we have:

#if defined(HAVE_FPU_CONTROL_T)
global fpu_control_t __fpu_control = _FPU_IEEE;
#else /* !defined(HAVE_FPU_CONTROL_T) && !defined(HAVE_SETFPUCW) */
global unsigned short __fpu_control = _FPU_IEEE;
#endif

My understanding is that this is supposed to set up the control word on program init, however it
does not appear to be doing so. For the time being, we have added

fedisableexcept(FE_ALL_EXCEPT);

to spvw.d, which appears to work but is a crude hack. The proper way of handling this would
probably be to use the new fenv.h support that is supposed to exist in glibc2 and is part of the
C99 spec, but I'm probably not the appropriate person to do a good job of that.

-dennis T

[Sam Steingold]

Logged In: YES
user_id=5735

Bruno, maybe you could address this?

[Sam Steingold]

Logged In: YES
user_id=5735

thank you for your bug report.
the bug has been fixed in the CVS tree.
you can either wait for the next release (recommended)
or check out the current CVS tree (see http://clisp.cons.org\)
and build CLISP from the sources (be advised that between
releases the CVS tree is very unstable and may not even build
on your platform).