On Sat, Jan 20, 2001 at 07:25:09PM -0500, Nathan Froyd wrote:
> I've gotten this error for the past couple times I've tried to compile
> CVS sbcl:
> Python version 1.0, VM version Intel x86 on 20 JAN 01 07:23:09 pm.
> Compiling: /home/nathan/src/sbcl/src/code/cross-float.lisp 31 OCT 00 08:10:04 pm
> Converted WITH-FLOAT-TRAPS-MASKED.
> Compiling DEFMACRO WITH-FLOAT-TRAPS-MASKED:
> Converted MASK-AND-SIGN-EXTEND.
> Compiling DEFUN MASK-AND-SIGN-EXTEND:
> Converted SINGLE-FLOAT-BITS.
> Compiling DEFUN SINGLE-FLOAT-BITS:
> Converted DOUBLE-FLOAT-BITS.
> Compiling DEFUN DOUBLE-FLOAT-BITS:
> [GC threshold exceeded with 5,443,016 bytes in use. Commencing GC.]
> [GC completed with 3,401,824 bytes retained and 2,041,192 bytes freed.]
> [GC will next occur when at least 5,401,824 bytes are in use.]
> Converted DOUBLE-FLOAT-LOW-BITS.
> Compiling DEFUN DOUBLE-FLOAT-LOW-BITS:
> Converted DOUBLE-FLOAT-HIGH-BITS.
> Compiling DEFUN DOUBLE-FLOAT-HIGH-BITS:
> Converted MAKE-SINGLE-FLOAT.
> Compiling DEFUN MAKE-SINGLE-FLOAT:
> Compilation unit aborted.
> Compilation aborted after 0:00:00.
> Error in batch processing:
> Arithmetic error FLOATING-POINT-OVERFLOW signalled.
> Any suggestions on how to further pinpoint the error? This is, of
> course, with CMUCL 18c -- don't know if 18b works, but I guess it would
> (it built 0.6.9.7 or whatever just fine).
Whether the cross-compilation host is SBCL or CMU CL, it's usually
easier to get information about errors if you run the compilation
interactively instead of as a script, since neither is very
sophisticated about noninteractive operation. Since your error occurs
when you're compiling cross-float.lisp (which doesn't happen when
building the target, only when building the cross-compiler) you only
need to run the steps in make-host-1.sh. So just type 'lisp' in your
shell, then cut the Lisp input from make-host-1.sh
;; (We want to have some limit on print length and print level
;; during bootstrapping because PRINT-OBJECT only gets set
;; up rather late, and running without PRINT-OBJECT it's easy
;; to fall into printing enormous (or infinitely circular)
;; low-level representations of things.)
(setf *print-level* 5 *print-length* 5)
(setf *host-obj-prefix* "obj/from-host/")
(sb!vm:genesis :c-header-file-name "src/runtime/sbcl.h")
and paste it into the Lisp command line. Unless something weird is
going on, it should fail in the same way. When it fails, either you
should be in the debugger at the location of the floating point
overflow, or the CMU CL compiler will have trapped the floating point
error and you'll only end up in the debugger later on. The first case
is easy: type BACKTRACE immediately and see what you see. The second
case is a little trickier. What I usually do in cases like that is
(trace error :break t)
and then retry the offending compilation. This usually gets me
into the debugger in the context of the original error, and then
I can get a backtrace and whatnot. (There are also other signal hacks
that have substantially the same effect.)
If it's not obvious from the debugger what the problem is, or if the
instructions above don't get you into the debugger at a useful place,
let me know.
As to whether it's an 18c-only problem: I just checked, and my working
version builds on Linux with what I think is CMU CL 18b, and is
certainly not 18c, since it's too old:
=> "CMU Common Lisp"
=> "release x86-linux 2.4.19 8 February 2000 build 456"
So it does seem to be an 18c-only issue.
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C