X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=7f62d6ce23ae7df5a428f8a25e3462e8222e3738;hb=ed891a4fd882d1b9fe066ab14bcf2107aea95baa;hp=4c64490f99abbe41f3d21bbdd262e5b923c64aa4;hpb=b4c650bad5478d99132fdf0e219d63cf07d0a5f8;p=sbcl.git

diff --git a/BUGS b/BUGS
index 4c64490..7f62d6c 100644
--- a/BUGS
+++ b/BUGS
@@ -479,6 +479,11 @@ WORKAROUND:
                (print (incf start 22))
                (print (incf start 26))))))
 
+  [ Update: 1.0.14.36 improved this quite a bit (20-25%) by
+    eliminating useless work from PROPAGATE-FROM-SETS -- but as alluded
+    below, maybe we should be smarter about when to decide a derived
+    type is "good enough". ]
+
   This example could be solved with clever enough constraint
   propagation or with SSA, but consider
 
@@ -551,11 +556,6 @@ WORKAROUND:
   c. The cross-compiler cannot inline functions defined in a non-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
@@ -1805,7 +1805,8 @@ WORKAROUND:
 
 419: stack-allocated indirect closure variables are not popped
 
-    (locally (declare (optimize speed (safety 0)))
+    (locally (declare (optimize sb-c::stack-allocate-dynamic-extent
+                                sb-c::stack-allocate-value-cells))
       (defun bug419 (x)
         (multiple-value-call #'list
           (eval '(values 1 2 3))
@@ -1818,7 +1819,13 @@ WORKAROUND:
               (declare (dynamic-extent #'mget #'mset))
               ((lambda (f g) (eval `(progn ,f ,g (values 4 5 6)))) #'mget #'mset))))))
 
-  (ASSERT (EQUAL (BUG419) '(1 2 3 4 5 6))) => failure
+  (ASSERT (EQUAL (BUG419 42) '(1 2 3 4 5 6))) => failure
+
+  Note: as of SBCL 1.0.26.29 this bug no longer affects user code, as
+  SB-C::STACK-ALLOCATE-VALUE-CELLS needs to be explicitly turned on for
+  that to happen. Proper fix for this bug requires (Nikodemus thinks)
+  storing the relevant LAMBDA-VARs in a :DYNAMIC-EXTENT cleanup, and
+  teaching stack analysis how to deal with them.
 
 420: The MISC.556 test from gcl/ansi-tests/misc.lsp fails hard.
 
@@ -1883,3 +1890,76 @@ Which should be fixed, the IR1, or the backend?
 behaves ...erratically. Reported by Kevin Reid on sbcl-devel
 2007-07-06. (We don't _have_ to check things like this, but we
 generally try to check returns in safe code, so we should here too.)
+
+424: toplevel closures and *CHECK-CONSISTENCY*
+
+ The following breaks under COMPILE-FILE if *CHECK-CONSISTENCY* is true.
+
+  (let ((exported-symbols-alist
+         (loop for symbol being the external-symbols of :cl
+               collect (cons symbol
+                             (concatenate 'string
+                                          "#"
+                                          (string-downcase symbol))))))
+    (defun hyperdoc-lookup (symbol)
+      (cdr (assoc symbol exported-symbols-alist))))
+
+ (Test-case adapted from CL-PPCRE.)
+
+425: reading from closed streams
+
+ Reported by Damien Cassou on sbcl-devel. REPL transcript follows:
+
+  * (open ".bashrc" :direction :input)
+  #<SB-SYS:FD-STREAM for "file /home/cassou/.bashrc" {A6ADFC9}>
+  * (defparameter *s* *)
+  *S*
+  * (read-line *s*)
+  "# -*- Mode: Sh -*-"
+  * (read-line *s*)
+  "# Files you make look like rw-r--r--"
+  * (open-stream-p *s*)
+  T
+  * (close *s*)
+  T
+  * (open-stream-p *s*)
+  NIL
+  * (read-line *s*)
+  "umask 022"
+
+ The problem is with the fast path using ansi-stream-cin-buffer not hitting
+ closed-flame.
+
+426: inlining failure involving multiple nested calls
+
+   (declaim (inline foo))
+   (defun foo (x y)
+     (cons x y))
+   (defun bar (x)
+     (foo (foo x x) (foo x x)))
+   ;; shows a full call to FOO
+   (disassemble 'bar)
+   ;; simple way to test this programmatically
+   (let ((code (sb-c::fun-code-header #'bar))
+         (foo (sb-impl::fdefinition-object 'foo nil)))
+     (loop for i from sb-vm:code-constants-offset below (sb-kernel:get-header-data code)
+           do (assert (not (eq foo (sb-kernel:code-header-ref code i))))))
+
+ This appears to be an ancient bug, inherited from CMUCL: reportedly
+ 18c does the same thing. RECOGNIZE-KNOWN-CALL correctly picks up only
+ one of the calls, but local call analysis fails to inline the call
+ for the second time. Nikodemus thinks (but is not 100% sure based on
+ very brief investigation) that the call that is not inlined is the
+ second nested one. A trivial fix is to call CHANGE-REF-LEAF in known
+ call for functions already inline converted there, but he is not sure
+ if this has adverse effects elsewhere.
+
+427: ANY-REG not good for primitive type T
+
+ ...which is true, of course, but the following should not complain
+ about it (on x86 and x86-64):
+
+  (sb-alien:with-alien ((buf (array (sb-alien:signed 8) 16))))
+
+ reported by Stelian Ionescu on sbcl-devel.
+