also unstable in several ways, including its inability
to really grok function declarations.
+ As of sbcl-0.7.5, sbcl's cross-compiler does run with
+ *TYPE-SYSTEM-INITIALIZED*; however, this bug remains.
+
7:
The "compiling top-level form:" output ought to be condensed.
Perhaps any number of such consecutive lines ought to turn into a
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
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)
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.
(defclass c0 (b) ())
(make-instance 'c19)
-177:
- (fixed in sbcl-0.7.4.24)
+ See also bug #140.
178: "AVER failure compiling confused THEs in FUNCALL"
In sbcl-0.7.4.24, compiling
(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.
+
+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.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.
+
DEFUNCT CATEGORIES OF BUGS
IR1-#:
These labels were used for bugs related to the old IR1 interpreter.
projects / sbcl.git / blobdiff