+174:
+ The error message from attempting to use a #\Return format
+ directive:
+ (format nil "~^M") ; replace "^M" with a literal #\Return
+ debugger invoked on condition of type SB-FORMAT::FORMAT-ERROR:
+ error in format: unknown format directive
+ ~
+ ^
+ is not terribly helpful; this is more noticeable than parallel cases
+ with e.g. #\Backspace because of the differing newline conventions
+ on various operating systems. (reported by Harald Hanche-Olsen on
+ cmucl-help 2002-05-31)
+
+176:
+ reported by Alexey Dejneka 08 Jun 2002 in sbcl-devel:
+ Playing with McCLIM, I've received an error "Unbound variable WRAPPER
+ in SB-PCL::CHECK-WRAPPER-VALIDITY".
+ (defun check-wrapper-validity (instance)
+ (let* ((owrapper (wrapper-of instance)))
+ (if (not (invalid-wrapper-p owrapper))
+ owrapper
+ (let* ((state (wrapper-state wrapper)) ; !!!
+ ...
+ I've tried to replace it with OWRAPPER, but now OBSOLETE-INSTANCE-TRAP
+ breaks with "NIL is not of type SB-KERNEL:LAYOUT".
+ SBCL 0.7.4.13.
+ partial fix: The undefined variable WRAPPER resulted from an error
+ in recent refactoring, as can be seen by comparing to the code in e.g.
+ sbcl-0.7.2. Replacing WRAPPER with OWRAPPER (done by WHN in sbcl-0.7.4.22)
+ should bring the code back to its behavior as of sbcl-0.7.2, but
+ that still leaves the OBSOLETE-INSTANCE-TRAP bug. An example of
+ input which triggers that bug is
+ (dotimes (i 20)
+ (let ((lastname (intern (format nil "C~D" (1- i))))
+ (name (intern (format nil "C~D" i))))
+ (eval `(defclass ,name
+ (,@(if (= i 0) nil (list lastname)))
+ ()))
+ (eval `(defmethod initialize-instance :after ((x ,name) &rest any)
+ (declare (ignore any))))))
+ (defclass b () ())
+ (defclass c0 (b) ())
+ (make-instance 'c19)
+
+ See also bug #140.
+
+178: "AVER failure compiling confused THEs in FUNCALL"
+ In sbcl-0.7.4.24, compiling
+ (defun bug178 (x)
+ (funcall (the function (the standard-object x))))
+ gives
+ failed AVER:
+ "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))"
+ This variant compiles OK, though:
+ (defun bug178alternative (x)
+ (funcall (the nil x)))
+
+181: "bad type specifier drops compiler into debugger"
+ Compiling
+ (in-package :cl-user)
+ (defun bar (x)
+ (declare (type 0 x))
+ (cons x x))
+ signals
+ bad thing to be a type specifier: 0
+ which seems fine, but also enters the debugger (instead of having
+ the compiler handle the error, convert it into a COMPILER-ERROR, and
+ continue compiling) which seems wrong.
+
+182: "SPARC/Linux floating point"
+ Evaluating (/ 1.0 0.0) at the prompt causes a Bus error and complete
+ death of the environment. Other floating point operations sometimes
+ return infinities when they should raise traps (e.g. the test case
+ for bug #146, (expt 2.0 12777)).
+
+183: "IEEE floating point issues"
+ Even where floating point handling is being dealt with relatively
+ well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the
+ accrued-exceptions and current-exceptions part of the fp control
+ word don't seem to bear much relation to reality. E.g. on
+ SPARC/SunOS:
+ * (/ 1.0 0.0)
+
+ debugger invoked on condition of type DIVISION-BY-ZERO:
+ arithmetic error DIVISION-BY-ZERO signalled
+ 0] (sb-vm::get-floating-point-modes)
+
+ (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
+ :ROUNDING-MODE :NEAREST
+ :CURRENT-EXCEPTIONS NIL
+ :ACCRUED-EXCEPTIONS (:INEXACT)
+ :FAST-MODE NIL)
+ 0] abort
+ * (sb-vm::get-floating-point-modes)
+ (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
+ :ROUNDING-MODE :NEAREST
+ :CURRENT-EXCEPTIONS (:INEXACT)
+ :ACCRUED-EXCEPTIONS (:INEXACT)
+ :FAST-MODE NIL)
+
+184: "division by zero becomes frozen into RATIO"
+ (reported by Wolfhard Buss on cmucl-imp 18 Jun 2002, fails on
+ sbcl-0.7.4.39 too)
+ * (/ 1 (/ 3 2) 0)
+ 1/0
+
+