+
+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.
+
+ See also bugs #45.c and #183
+
+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.
+
+ (Python LET-converts KIDIFY1 into KID-FROB, then tries to inline
+ expand KID-FROB into %ZEEP. Having partially done it, it sees a call
+ of KIDIFY1, which already does not exist. So it gives up on
+ expansion, leaving garbage consisting of infinished blocks of the
+ partially converted function.)
+
+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.)
+
+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.
+
+172:
+ sbcl's treatment of at least macro lambda lists is too permissive;
+ e.g., in sbcl-0.7.3.7:
+ (defmacro foo (&rest rest bar) `(,bar ,rest))
+ (macroexpand '(foo quux zot)) -> (QUUX (QUUX ZOT))
+ whereas section 3.4.4 of the CLHS doesn't allow required parameters
+ to come after the rest argument.
+
+173:
+ The compiler sometimes tries to constant-fold expressions before
+ it checks to see whether they can be reached. This can lead to
+ bogus warnings about errors in the constant folding, e.g. in code
+ like
+ (WHEN X
+ (WRITE-STRING (> X 0) "+" "0"))
+ compiled in a context where the compiler can prove that X is NIL,
+ and the compiler complains that (> X 0) causes a type error because
+ NIL isn't a valid argument to #'>. Until sbcl-0.7.4.10 or so this
+ caused a full WARNING, which made the bug really annoying because then
+ COMPILE and COMPILE-FILE returned FAILURE-P=T for perfectly legal
+ code. Since then the warning has been downgraded to STYLE-WARNING,
+ so it's still a bug but at least it's a little less annoying.
+
+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)))
+
+ (since 0.7.8.9 it does not signal an error; see also bug 199)
+
+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)
+
+185: "top-level forms at the REPL"
+ * (locally (defstruct foo (a 0 :type fixnum)))
+ gives an error:
+ ; caught ERROR:
+ ; (in macroexpansion of (SB-KERNEL::%DELAYED-GET-COMPILER-LAYOUT BAR))
+ however, compiling and loading the same expression in a file works
+ as expected.
+
+187: "type inference confusion around DEFTRANSFORM time"
+ (reported even more verbosely on sbcl-devel 2002-06-28 as "strange
+ bug in DEFTRANSFORM")
+ After the file below is compiled and loaded in sbcl-0.7.5, executing
+ (TCX (MAKE-ARRAY 4 :FILL-POINTER 2) 0)
+ at the REPL returns an adjustable vector, which is wrong. Presumably
+ somehow the DERIVE-TYPE information for the output values of %WAD is
+ being mispropagated as a type constraint on the input values of %WAD,
+ and so causing the type test to be optimized away. It's unclear how
+ hand-expanding the DEFTRANSFORM would change this, but it suggests
+ the DEFTRANSFORM machinery (or at least the way DEFTRANSFORMs are
+ invoked at a particular phase) is involved.
+ (cl:in-package :sb-c)
+ (eval-when (:compile-toplevel)
+ ;;; standin for %DATA-VECTOR-AND-INDEX
+ (defknown %dvai (array index)
+ (values t t)
+ (foldable flushable))
+ (deftransform %dvai ((array index)
+ (vector t)
+ *
+ :important t)
+ (let* ((atype (continuation-type array))
+ (eltype (array-type-specialized-element-type atype)))
+ (when (eq eltype *wild-type*)
+ (give-up-ir1-transform
+ "specialized array element type not known at compile-time"))
+ (when (not (array-type-complexp atype))
+ (give-up-ir1-transform "SIMPLE array!"))
+ `(if (array-header-p array)
+ (%wad array index nil)
+ (values array index))))
+ ;;; standin for %WITH-ARRAY-DATA
+ (defknown %wad (array index (or index null))
+ (values (simple-array * (*)) index index index)
+ (foldable flushable))
+ ;;; (Commenting out this optimizer causes the bug to go away.)
+ (defoptimizer (%wad derive-type) ((array start end))
+ (let ((atype (continuation-type array)))
+ (when (array-type-p atype)
+ (values-specifier-type
+ `(values (simple-array ,(type-specifier
+ (array-type-specialized-element-type atype))
+ (*))
+ index index index)))))
+ ) ; EVAL-WHEN
+ (defun %wad (array start end)
+ (format t "~&in %WAD~%")
+ (%with-array-data array start end))
+ (cl:in-package :cl-user)
+ (defun tcx (v i)
+ (declare (type (vector t) v))
+ (declare (notinline sb-kernel::%with-array-data))
+ ;; (Hand-expending DEFTRANSFORM %DVAI here also causes the bug to
+ ;; go away.)
+ (sb-c::%dvai v i))
+
+188: "compiler performance fiasco involving type inference and UNION-TYPE"
+ (In sbcl-0.7.6.10, DEFTRANSFORM CONCATENATE was commented out until this
+ bug could be fixed properly, so you won't see the bug unless you restore
+ the DEFTRANSFORM by hand.) In sbcl-0.7.5.11 on a 700 MHz Pentium III,
+ (time (compile
+ nil
+ '(lambda ()
+ (declare (optimize (safety 3)))
+ (declare (optimize (compilation-speed 2)))
+ (declare (optimize (speed 1) (debug 1) (space 1)))
+ (let ((fn "if-this-file-exists-the-universe-is-strange"))
+ (load fn :if-does-not-exist nil)
+ (load (concatenate 'string fn ".lisp") :if-does-not-exist nil)
+ (load (concatenate 'string fn ".fasl") :if-does-not-exist nil)
+ (load (concatenate 'string fn ".misc-garbage")
+ :if-does-not-exist nil)))))
+ reports
+ 134.552 seconds of real time
+ 133.35156 seconds of user run time
+ 0.03125 seconds of system run time
+ [Run times include 2.787 seconds GC run time.]
+ 0 page faults and
+ 246883368 bytes consed.
+ BACKTRACE from Ctrl-C in the compilation shows that the compiler is
+ thinking about type relationships involving types like
+ #<UNION-TYPE
+ (OR (INTEGER 576 576)
+ (INTEGER 1192 1192)
+ (INTEGER 2536 2536)
+ (INTEGER 1816 1816)
+ (INTEGER 2752 2752)
+ (INTEGER 1600 1600)
+ (INTEGER 2640 2640)
+ (INTEGER 1808 1808)
+ (INTEGER 1296 1296)
+ ...)>)[:EXTERNAL]
+
+190: "PPC/Linux pipe? buffer? bug"
+ In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs
+ on the PPC/Linux platform, waiting for a zombie env process. This
+ is a classic symptom of buffer filling and deadlock, but it seems
+ only sporadically reproducible.
+
+191: "Miscellaneous PCL deficiencies"
+ (reported by Alexey Dejneka sbcl-devel 2002-08-04)
+ a. DEFCLASS does not inform the compiler about generated
+ functions. Compiling a file with
+ (DEFCLASS A-CLASS ()
+ ((A-CLASS-X)))
+ (DEFUN A-CLASS-X (A)
+ (WITH-SLOTS (A-CLASS-X) A
+ A-CLASS-X))
+ results in a STYLE-WARNING:
+ undefined-function
+ SB-SLOT-ACCESSOR-NAME::|COMMON-LISP-USER A-CLASS-X slot READER|
+
+ APD's fix for this was checked in to sbcl-0.7.6.20, but Pierre
+ Mai points out that the declamation of functions is in fact
+ incorrect in some cases (most notably for structure
+ classes). This means that at present erroneous attempts to use
+ WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS
+ won't get the corresponding STYLE-WARNING.
+ c. the examples in CLHS 7.6.5.1 (regarding generic function lambda
+ lists and &KEY arguments) do not signal errors when they should.
+
+192: "Python treats free type declarations as promises."
+ b. What seemed like the same fundamental problem as bug 192a, but
+ was not fixed by the same (APD "more strict type checking
+ sbcl-devel 2002-08-97) patch:
+ (DOTIMES (I ...) (DOTIMES (J ...) (DECLARE ...) ...)):
+ (declaim (optimize (speed 1) (safety 3)))
+ (defun trust-assertion (i)
+ (dotimes (j i)
+ (declare (type (mod 4) i)) ; when commented out, behavior changes!
+ (unless (< i 5)
+ (print j))))
+ (trust-assertion 6) ; prints nothing unless DECLARE is commented out
+
+ (see bug 203)
+
+193: "unhelpful CLOS error reporting when the primary method is missing"
+ In sbcl-0.7.7, when
+ (defmethod foo :before ((x t)) (print x))
+ is the only method defined on FOO, the error reporting when e.g.
+ (foo 12)
+ is relatively unhelpful:
+ There is no primary method for the generic function
+ #<STANDARD-GENERIC-FUNCTION FOO (1)>.
+ with the offending argument nowhere visible in the backtrace. This
+ continues even if there *are* primary methods, just not for the
+ specified arg type, e.g.
+ (defmethod foo ((x character)) (print x))
+ (defmethod foo ((x string)) (print x))
+ (defmethod foo ((x pathname)) ...)
+ In that case it could be very helpful to know what argument value is
+ falling through the cracks of the defined primary methods, but the
+ error message stays the same (even BACKTRACE doesn't tell you what the
+ bad argument value is).
+
+194: "no error from (THE REAL '(1 2 3)) in some cases"
+ fixed parts:
+ a. In sbcl-0.7.7.9,
+ (multiple-value-prog1 (progn (the real '(1 2 3))))
+ returns (1 2 3) instead of signalling an error. This was fixed by
+ APD's "more strict type checking patch", but although the fixed
+ code (in sbcl-0.7.7.19) works (signals TYPE-ERROR) interactively,
+ it's difficult to write a regression test for it, because
+ (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3)))))
+ still returns (1 2 3).
+ still-broken parts:
+ b. (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3)))))
+ returns (1 2 3). (As above, this shows up when writing regression
+ tests for fixed-ness of part a.)
+ c. Also in sbcl-0.7.7.9, (IGNORE-ERRORS (THE REAL '(1 2 3))) => (1 2 3).
+ d. At the REPL,
+ (null (ignore-errors
+ (let ((arg1 1)
+ (arg2 (identity (the real #(1 2 3)))))
+ (if (< arg1 arg2) arg1 arg2))))
+ => T
+ but putting the same expression inside (DEFUN FOO () ...),
+ (FOO) => NIL.
+ notes:
+ * Actually this entry is probably multiple bugs, as
+ Alexey Dejneka commented on sbcl-devel 2002-09-03:)
+ I don't think that placing these two bugs in one entry is
+ a good idea: they have different explanations. The second
+ (min 1 nil) is caused by flushing of unused code--IDENTITY
+ can do nothing with it. So it is really bug 122. The first
+ (min nil) is due to M-V-PROG1: substituting a continuation
+ for the result, it forgets about type assertion. The purpose
+ of IDENTITY is to save the restricted continuation from
+ inaccurate transformations.
+ * Alexey Dejneka pointed out that
+ (IGNORE-ERRORS (IDENTITY (THE REAL '(1 2 3))))
+ works as it should. Also
+ (IGNORE-ERRORS (VALUES (THE REAL '(1 2 3))))
+ works as it should. Perhaps this is another case of VALUES type
+ intersections behaving in non-useful ways?
+
+199: "hairy FUNCTION types confuse the compiler"
+ (reported by APD sbcl-devel 2002-09-15)
+ (DEFUN MUR (F)
+ (EQ NIL (FUNCALL F)))
+
+ (DEFUN FOO (F X)
+ (DECLARE (TYPE (AND FUNCTION (SATISFIES MUR)) F))
+ (FUNCALL F X))
+
+ fails to compile, printing
+ failed AVER:
+ "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))"
+
+ APD further reports that this bug is not present in CMUCL.
+
+ (this case was fixed in 0.7.8.9; see also bug 178)
+
+201: "Incautious type inference from compound CONS types"
+ (reported by APD sbcl-devel 2002-09-17)
+ (DEFUN FOO (X)
+ (LET ((Y (CAR (THE (CONS INTEGER *) X))))
+ (SETF (CAR X) NIL)
+ (FORMAT NIL "~S IS ~S, Y = ~S"
+ (CAR X)
+ (TYPECASE (CAR X)
+ (INTEGER 'INTEGER)
+ (T '(NOT INTEGER)))
+ Y)))
+
+ (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"
+
+203:
+ Compiler does not check THEs on unused values, e.g. in
+
+ (progn (the real (list 1)) t)
+
+ This situation may appear during optimizing away degenerate cases of
+ certain functions: see bugs 54, 192b.
+
+205: "environment issues in cross compiler"
+ (These bugs have no impact on user code, but should be fixed or
+ documented.)
+ a. Macroexpanders introduced with MACROLET are defined in the null
+ lexical environment.
+ b. The body of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) is evaluated in
+ the null lexical environment.
+
+206: ":SB-FLUID feature broken"
+ (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07)
+ Enabling :SB-FLUID in the target-features list in sbcl-0.7.8 breaks
+ the build.
+
+207: "poorly distributed SXHASH results for compound data"
+ SBCL's SXHASH could probably try a little harder. ANSI: "the
+ intent is that an implementation should make a good-faith
+ effort to produce hash-codes that are well distributed
+ within the range of non-negative fixnums". But
+ (let ((hits (make-hash-table)))
+ (dotimes (i 16)
+ (dotimes (j 16)
+ (let* ((ij (cons i j))
+ (newlist (push ij (gethash (sxhash ij) hits))))
+ (when (cdr newlist)
+ (format t "~&collision: ~S~%" newlist))))))
+ reports lots of collisions in sbcl-0.7.8. A stronger MIX function
+ would be an obvious way of fix. Maybe it would be acceptably efficient
+ to redo MIX using a lookup into a 256-entry s-box containing
+ 29-bit pseudorandom numbers?
+
+208: "package confusion in PCL handling of structure slot handlers"
+ In sbcl-0.7.8 compiling and loading
+ (in-package :cl)
+ (defstruct foo (slot (error "missing")) :type list :read-only t)
+ (defmethod print-object ((foo foo) stream) (print nil stream))
+ causes CERROR "attempting to modify a symbol in the COMMON-LISP
+ package: FOO-SLOT". (This is fairly bad code, but still it's hard
+ to see that it should cause symbols to be interned in the CL package.)
+
+209: "DOCUMENTATION generic function has wrong argument precedence order"
+ (fixed in sbcl-0.7.8.39)
+
+210: "unsafe evaluation of DEFSTRUCT slot initforms in BOA constructors"
+ (fixed in sbcl-0.7.8.35)
+
+211: "keywords processing"
+ a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
+ number of keyword arguments.
+ b. Compiling of a local call with an unknown key and
+ :ALLOW-OTHER-KEYS T should not cause a WARNING.
+ c. Compiler should not warn on an unknown key :ALLOW-OTHER-KEYS.
+ d. :ALLOW-OTHER-KEYS should be allowed as an ordinary key parameter.
+
+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.