Ticket #707 (closed defect: fixed)

Opened 7 years ago

Last modified 7 years ago

spurious floating-point exceptions

Reported by: rme Owned by: rme
Priority: normal Milestone:
Component: Runtime (threads, GC) Version: trunk
Keywords: Cc:


It looks like some exception flags get left on in the MXCSR somehow.

/* fp.c -- compile with cc -shared fp.c -o fp.dylib */

double rme_fdiv(double x, double y)
    return x / y;

double rme_nan()
    return rme_fdiv(0.0, 0.0);

From lisp:

? (open-shared-library "/Users/rme/fp.dylib")
#<SHLIB /Users/rme/fp.dylib #x30200053443D>
? (external-call "rme_nan" :double-float)
1D+-0 #| not-a-number |#
? (log 1 2)
>        performing LOG on (1.0)
> While executing: %FP-ERROR-FROM-STATUS, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.
1 > :pop

? (log 1 2)

Change History

comment:1 Changed 7 years ago by rme

(In [13994]) Clear tcr.ffi_exception in .SPffcall/.SPffcall_return_registers before calling foreign code.

If foreign code generates an fp exception, we put the MXCSR into tcr.ffi_exception. This value hangs around until another foreign fp exception takes place, or something from lisp calls %get-post-ffi-exception, which clears tcr.ffi_exception as a side-effect.

This was causing lisp functions (e.g., LOG, COS, etc.) to signal spurious floating-point errors: even though the call out to the C library function (e.g., log) produced no exception, the lisp code that looks for a post-ffi fp exception would sometimes see one anyway, left over from some ff-call.

See ticket:707.

comment:2 Changed 7 years ago by rme

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.