GC, so that thereafter memory usage can never be reduced below that
level.
-96:
- The TRACE facility can't be used on some kinds of functions.
- (Basically, the breakpoint facility was incompletely implemented
- in the X86 port of CMU CL, and hasn't been fixed in SBCL.)
-
98:
In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU
CL), out-of-line structure slot setters are horribly inefficient
(let ((x (1+ x)))
(call-next-method)))
Now (FOO 3) should return 3, but instead it returns 4.
-
-137:
- (SB-DEBUG:BACKTRACE) output should start with something
- including the name BACKTRACE, not (as in 0.pre7.88)
- just "0: (\"hairy arg processor\" ...)". Until about
- sbcl-0.pre7.109, the names in BACKTRACE were all screwed
- up compared to the nice useful names in sbcl-0.6.13.
- Around sbcl-0.pre7.109, they were mostly fixed by using
- NAMED-LAMBDA to implement DEFUN. However, there are still
- some screwups left, e.g. as of sbcl-0.pre7.109, there are
- still some functions named "hairy arg processor" and
- "SB-INT:&MORE processor".
+
+140:
+ (reported by Alexey Dejneka sbcl-devel 2002-01-03)
+
+ SUBTYPEP does not work well with redefined classes:
+ ---
+ * (defclass a () ())
+ #<STANDARD-CLASS A>
+ * (defclass b () ())
+ #<STANDARD-CLASS B>
+ * (subtypep 'b 'a)
+ NIL
+ T
+ * (defclass b (a) ())
+ #<STANDARD-CLASS B>
+ * (subtypep 'b 'a)
+ T
+ T
+ * (defclass b () ())
+ #<STANDARD-CLASS B>
+
+ ;;; And now...
+ * (subtypep 'b 'a)
+ T
+ T
+
+ This bug was fixed in sbcl-0.7.4.1 by invalidating the PCL wrapper
+ class upon redefinition. Unfortunately, doing so causes bug #176 to
+ appear. Pending further investication, one or other of these bugs
+ might be present at any given time.
141:
Pretty-printing nested backquotes doesn't work right, as
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.
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.
+ 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
+
+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.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]
DEFUNCT CATEGORIES OF BUGS
IR1-#: