(sorry for the duplicate mail, but this one should have the attachment!)
I've looked into the wait-for-floating-point-exceptions issue
in handler-case, brought up on cmucl-imp around 2001-03-28.
This was also on the TODO list for pre-0.7-SBCL (referring to
Bill's mail on 2001-05-09).
There was a problem in CMUCL, that caused a floating-point-exception,
and for that the patch for handler-case was made (more onto that,
Attached is a patch that has the float-wait instruction in the
handler-case macro, ported from CMUCL.
It turned out, that CMUCL was using another version of the macro,
that was commented out in the CMUCL-sources, but was reinstated
around 2000-07. A comment in the CVS logs for SBCL (sbcl-0.6.7.2),
said that the older-version of handler-case was deleted.
Hmm, I'm not sure, which one the older one was ... ;)
The new code looks a bit more "modern" and cleaner, since it uses
a TAGBODY for directing the control-flow, but that's merely a
matter of style.
Well, more importantly, since the original code to trigger the bug,
given by Christophe Rhodes, does yield no error in SBCL, neither
with the old/new handler-case: I'm not sure, if we should include
the patch, but we could do it as CMUCL did, with the old code commented
The patch may still be relevant for SBCL, but I haven't found a way
to trigger the bug, yet.
Here are some important pieces from cmucl-imp for that matter:
The code that triggered the problem:
* (defun make-single-float (bits)
(if (zerop bits) ; IEEE float special case
(let ((sign (ecase (ldb (byte 1 31) bits)
(expt (- (ldb (byte 8 23) bits) 127))
(mant (* (logior (ldb (byte 23 0) bits)
(ash 1 23))
(expt 0.5 23))))
(* sign (expt 2.0 expt) mant))))
* (make-single-float 1)
* (compile 'make-single-float)
Compiling LAMBDA (BITS):
Arithmetic error FLOATING-POINT-OVERFLOW signalled.
Subject: Re: Compiler bug?
From: Raymond Toy <toy@...>
Date: 19 Apr 2001 10:49:06 -0400
Raymond> 1. The underlying problem is in safe-expt, despite what the
Raymond> says. The computation is (safe-expt 2.0 128), which
Raymond> 2. The real cause of 1 is that handler-case in safe-expt
Raymond> correctly handle the floating-point overflow.
Raymond> 3. The backtrace is totally wrong. TWO-ARG-= can't
possibly cause an
Figured out what the problem is. If you macroexpand the handler-case
and handler-bind in safe-expt, you get something like:
(DECLARE (IGNORE CONDITIONS::TEMP))
(MULTIPLE-VALUE-PROG1 (PROGN (RETURN-FROM #:G946 (EXPT X Y)))
Since FP exceptions aren't signaled until the *next* FP instruction,
the expt returns and bypasses the float-wait. I think handler-bind
needs the float-wait call.
The appended patch does this by adding a float-wait for
handler-case. With this change, FP errors should be handled at the
Martin Atzmueller <martin@...>