+145:
+ ANSI allows types `(COMPLEX ,FOO) to use very hairy values for
+ FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL
+ COMPLEX implementation didn't deal with this, and hasn't been
+ upgraded to do so. (This doesn't seem to be a high priority
+ conformance problem, since seems hard to construct useful code
+ where it matters.)
+
+146:
+ Floating point errors are reported poorly. E.g. on x86 OpenBSD
+ with sbcl-0.7.1,
+ * (expt 2.0 12777)
+ debugger invoked on condition of type SB-KERNEL:FLOATING-POINT-EXCEPTION:
+ An arithmetic error SB-KERNEL:FLOATING-POINT-EXCEPTION was signalled.
+ No traps are enabled? How can this be?
+ It should be possible to be much more specific (overflow, division
+ by zero, etc.) and of course the "How can this be?" should be fixable.
+
+148:
+ In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file
+ (in-package :cl-user)
+ (defvar *thing*)
+ (defvar *zoom*)
+ (defstruct foo bar bletch)
+ (defun %zeep ()
+ (labels ((kidify1 (kid)
+ )
+ (kid-frob (kid)
+ (if *thing*
+ (setf sweptm
+ (m+ (frobnicate kid)
+ sweptm))
+ (kidify1 kid))))
+ (declare (inline kid-frob))
+ (map nil
+ #'kid-frob
+ (the simple-vector (foo-bar perd)))))
+ fails with
+ debugger invoked on condition of type TYPE-ERROR:
+ The value NIL is not of type SB-C::NODE.
+ The location of this failure has moved around as various related
+ issues were cleaned up. As of sbcl-0.7.1.9, it occurs in
+ NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
+
+153:
+ (essentially the same problem as a CMU CL bug reported by Martin
+ Cracauer on cmucl-imp 2002-02-19)
+ There is a hole in structure slot type checking. Compiling and LOADing
+ (declaim (optimize safety))
+ (defstruct foo
+ (bla 0 :type fixnum))
+ (defun f ()
+ (let ((foo (make-foo)))
+ (setf (foo-bla foo) '(1 . 1))
+ (format t "Is ~a of type ~a a cons? => ~a~%"
+ (foo-bla foo)
+ (type-of (foo-bla foo))
+ (consp (foo-bla foo)))))
+ (f)
+ should signal an error, but in sbcl-0.7.1.21 instead gives the output
+ Is (1 . 1) of type CONS a cons? => NIL
+ without signalling an error.
+
+154:
+ There's some sort of problem with aborting back out of the debugger
+ after a %DETECT-STACK-EXHAUSTION error in sbcl-0.7.1.38. In some cases
+ telling the debugger to ABORT doesn't get you back to the main REPL,
+ but instead just gives you another stack exhaustion error. The problem
+ doesn't occur in the trivial case
+ * (defun frob () (frob) (frob))
+ FROB
+ * (frob)
+ but it has happened in more complicated cases (which I haven't
+ figured out how to reproduce).
+
+156:
+ FUNCTION-LAMBDA-EXPRESSION doesn't work right in 0.7.0 or 0.7.2.9:
+ * (function-lambda-expression #'(lambda (x) x))
+ debugger invoked on condition of type TYPE-ERROR:
+ The value NIL is not of type SB-C::DEBUG-SOURCE
+ (reported by Alexey Dejneka sbcl-devel 2002-04-12)
+
+157:
+ Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
+ UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument.
+ (reported by Alexey Dejneka sbcl-devel 2002-04-12)
+
+162:
+ (reported by Robert E. Brown 2002-04-16)
+ When a function is called with too few arguments, causing the
+ debugger to be entered, the uninitialized slots in the bad call frame
+ seem to cause GCish problems, being interpreted as tagged data even
+ though they're not. In particular, executing ROOM in the
+ debugger at that point causes AVER failures:
+ * (machine-type)
+ "X86"
+ * (lisp-implementation-version)
+ "0.7.2.12"
+ * (typep 10)
+ ...
+ 0] (room)
+ ...
+ failed AVER: "(SAP= CURRENT END)"
+ (Christophe Rhodes reports that this doesn't occur on the SPARC, which
+ isn't too surprising since there are many differences in stack
+ implementation and GC conservatism between the X86 and other ports.)
+
+165:
+ Array types with element-types of some unknown type are falsely being
+ assumed to be of type (ARRAY T) by the compiler in some cases. The
+ following code demonstrates the problem:
+
+ (defun foo (x)
+ (declare (type (vector bar) x))
+ (aref x 1))
+ (deftype bar () 'single-float)
+ (foo (make-array 3 :element-type 'bar))
+ -> TYPE-ERROR "The value #(0.0 0.0 0.0) is not of type (VECTOR BAR)."
+ (typep (make-array 3 :element-type 'bar) '(vector bar))
+ -> T
+
+ The easy solution is to make the functions which depend on knowing
+ the upgraded-array-element-type (in compiler/array-tran and
+ compiler/generic/vm-tran as of sbcl-0.7.3.x) be slightly smarter about
+ unknown types; an alternative is to have the
+ specialized-element-type slot in the ARRAY-TYPE structure be
+ *WILD-TYPE* for UNKNOWN-TYPE element types.
+
+166:
+ Compiling
+ (in-package :cl-user)
+ (defstruct uustk)
+ (defmethod permanentize ((uustk uustk))
+ (flet ((frob (hash-table test-for-deletion)
+ )
+ (obj-entry.stale? (oe)
+ (destructuring-bind (key . datum) oe
+ (declare (type simple-vector key))
+ (deny0 (void? datum))
+ (some #'stale? key))))
+ (declare (inline frob obj-entry.stale?))
+ (frob (uustk.args-hash->obj-alist uustk)
+ #'obj-entry.stale?)
+ (frob (uustk.hash->memoized-objs-list uustk)
+ #'objs.stale?))
+ (call-next-method))
+ in sbcl-0.7.3.11 causes an assertion failure,
+ failed AVER:
+ "(NOT
+(AND (NULL (BLOCK-SUCC B))
+ (NOT (BLOCK-DELETE-P B))
+ (NOT (EQ B (COMPONENT-HEAD #)))))"
+
+167:
+ In sbcl-0.7.3.11, compiling the (illegal) code
+ (in-package :cl-user)
+ (defmethod prove ((uustk uustk))
+ (zap ((frob () nil))
+ (frob)))
+ gives the (not terribly clear) error message
+ ; caught ERROR:
+ ; (during macroexpansion of (DEFMETHOD PROVE ...))
+ ; can't get template for (FROB NIL NIL)
+ The problem seems to be that the code walker used by the DEFMETHOD
+ macro is unhappy with the illegal syntax in the method body, and
+ is giving an unclear error message.
+
+168:
+ (reported by Dan Barlow on sbcl-devel 2002-05-10)
+ In sbcl-0.7.3.12, doing
+ (defstruct foo bar baz)
+ (compile nil (lambda (x) (or x (foo-baz x))))
+ gives an error
+ debugger invoked on condition of type SB-INT:BUG:
+ full call to SB-KERNEL:%INSTANCE-REF
+ This is probably a bug in SBCL itself. [...]
+ Since this is a reasonable user error, it shouldn't be reported as
+ an SBCL bug.
+
+169:
+ (reported by Alexey Dejneka on sbcl-devel 2002-05-12)
+ * (defun test (n)
+ (let ((*x* n))
+ (declare (special *x*))
+ (getx)))
+ ; in: LAMBDA NIL
+ ; (LET ((*X* N))
+ ; (DECLARE (SPECIAL *X*))
+ ; (GETX))
+ ;
+ ; caught STYLE-WARNING:
+ ; using the lexical binding of the symbol *X*, not the
+ ; dynamic binding, even though the symbol name follows the usual naming
+ ; convention (names like *FOO*) for special variables
+ ; compilation unit finished
+ ; caught 1 STYLE-WARNING condition
+ But the code works as it should. Checked in 0.6.12.43 and later.
+
+171:
+ (reported by Pierre Mai while investigating bug 47):
+ (DEFCLASS FOO () ((A :SILLY T)))
+ signals a SIMPLE-ERROR, not a PROGRAM-ERROR.
+
+DEFUNCT CATEGORIES OF BUGS
+ IR1-#:
+ These labels were used for bugs related to the old IR1 interpreter.
+ The # values reached 6 before the category was closed down.