[Openmcl-devel] Infinity and NaN

[R. Matthew Emerson]

On Jul 19, 2010, at 12:35 PM, Liam Healy wrote:

> I'm having trouble defining variables that create infinities and NaNs.
> I am using GSL
> http://www.gnu.org/software/gsl/manual/html_node/Infinities-and-Not_002da_002dnumber.html
> to do this; here for example is my definition
> 
> (defconstant +nan+
>  (ignore-errors
>    (cffi:foreign-funcall "gsl_nan" :double)))
> 
> If I put this form into the listener, it loads fine, and
> 
> +nan+
> 1D+-0 #| not-a-number |#
> 
> However, if I put this definition into a file to compile it,
> 
> ASDF could not load gsll because FLOATING-POINT-INVALID-OPERATION detected
> performing LOG on (1.0).
>> Error: FLOATING-POINT-INVALID-OPERATION detected
>>       performing LOG on (1.0)
>> While executing: CCL::%FP-ERROR-FROM-STATUS, in process listener(1).
>> Type :POP to abort, :R for a list of available restarts.
>> Type :? for other options.
> 
> I'm not sure where this is coming from, nor why taking the log
> of 1.0 should be a problem.

I recently changed how ccl deals with floating-point exceptions in foreign code (on x86-64), so I may have introduced or exposed a bug here.

At the risk of boring everyone, I will explain the change.

We used to unconditionally mask (disable) all floating point exceptions when calling a foreign function.  It's not free to save/restore the MXCSR (the register that contains fp status and control bits) around every foreign function call, so we now leave fp exceptions enabled (as configured by ccl:set-fpu-mode).  The runtime will notice when an fp exception takes place in foreign code, mask all fp exceptions, and try the call again.  When we return from the foreign function call, we check to see if the runtime handled an fp exception: if it did, we save the fp exception state and restore lisp's MXCSR (again, as set by ccl:set-fpu-mode).

leo2007 on #ccl pasted a backtrace of this problem: http://paste.pocoo.org/show/239363

Anyway, we're looking at it.

I guess that what happened in this case is that some operation somewhere has set the exception flags and left them behind;  later, when LOG checks them, a spurious error is signaled.

By the way, there are constants ccl::double-float-{positive,negative}-infinity, and ccl::double-float-nan. I wonder if we should be exporting those.

> (lisp-implementation-version)
> "Version 1.6-dev-r13980M-trunk  (LinuxX8664)"
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel