+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|
+ c. the examples in CLHS 7.6.5.1 (regarding generic function lambda
+ lists and &KEY arguments) do not signal errors when they should.
+