X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=7f5faabe0095b7acc7c2844bafd38781ed05f356;hb=b84b7f3a3c58909c6e252aba8c97148c9ad917b7;hp=db74388d702bdc6a7b82b02e34faf755e34a80da;hpb=7c864061be7f43f15249580f1e3fb7cac861c784;p=sbcl.git

diff --git a/BUGS b/BUGS
index db74388..7f5faab 100644
--- a/BUGS
+++ b/BUGS
@@ -584,11 +584,6 @@ WORKAROUND:
   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
@@ -1130,13 +1125,6 @@ WORKAROUND:
   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.
@@ -1376,6 +1364,97 @@ WORKAROUND:
   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-#: