X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=55d9b4fcbe01df5ffe7c9b443de4007d7aa93ba1;hb=14115e1756e5764ef9e200f331912ae3a48cc4a2;hp=2917c5c0de079278900137b8f69c0303b698b00b;hpb=bbe8a5877fab63f5c159e6c481a449e68b0a5d8f;p=sbcl.git

diff --git a/BUGS b/BUGS
index 2917c5c..55d9b4f 100644
--- a/BUGS
+++ b/BUGS
@@ -84,12 +84,6 @@ WORKAROUND:
 
   d: (fixed in 0.8.1.5)
 
-27:
-  Sometimes (SB-EXT:QUIT) fails with 
-	Argh! maximum interrupt nesting depth (4096) exceeded, exiting
-	Process inferior-lisp exited abnormally with code 1
-  I haven't noticed a repeatable case of this yet.
-
 33:
   And as long as we're wishing, it would be awfully nice if INSPECT could
   also report on closures, telling about the values of the bound variables.
@@ -174,6 +168,9 @@ WORKAROUND:
   e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN
   and Pierre Mai.)
 
+  (Actually this has changed changed since, and types as above are
+  now supported. This may be a bug.)
+
 83:
   RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
   RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
@@ -732,11 +729,7 @@ WORKAROUND:
 
   a. (lambda () (svref (make-array 8 :adjustable t) 1))
 
-  b. (lambda (x)
-       (list (let ((y (the real x)))
-               (unless (floatp y) (error ""))
-               y)
-             (integer-length x)))
+  b. (fixed at some point before 1.0.4.10)
 
   c. (lambda (x)
        (declare (optimize (debug 0)))
@@ -1476,18 +1469,6 @@ WORKAROUND:
   tries to find and remove a method with an incompatible lambda list
   from the unrelated generic function.
 
-381: incautious calls to EQUAL in fasl dumping
-  Compiling 
-    (frob #(#1=(a #1#)))
-    (frob #(#1=(b #1#)))
-    (frob #(#1=(a #1#)))
-  in sbcl-0.9.0 causes CONTROL-STACK-EXHAUSTED. My (WHN) impression 
-  is that this follows from the use of (MAKE-HASH-TABLE :TEST 'EQUAL)
-  to detect sharing, in which case fixing it might require either 
-  getting less ambitious about detecting shared list structure, or 
-  implementing the moral equivalent of EQUAL hash tables in a 
-  cycle-tolerant way.
-
 382: externalization unexpectedly changes array simplicity
   COMPILE-FILE and LOAD
     (defun foo ()
@@ -1807,7 +1788,60 @@ WORKAROUND:
   implementation of read circularity, using a symbol as a marker for
   the previously-referenced object.
 
-411: NAN issues on x86-64
-  Test :NAN-COMPARISONS in float.pure.lisp fails on x86-64, and has been
-  disabled on those platforms. Since x86 does not exhibit any problems
-  the problem is probably with the new FP implementation.
+413: type-errors in ROOM
+
+  (defvar *a* (make-array (expt 2 27)))
+  (room)
+
+  Causes a type-error on 32bit SBCL, as various byte-counts in ROOM
+  implementation overrun fixnums. 
+
+  This was fixed in 1.0.4.89, but the patch was reverted as it caused
+  ROOM to cons sufficiently to make running it in a loop deadly on
+  GENCGC: newly allocated objects survived to generation 1, where next
+  call to ROOM would see them, and allocate even more...
+
+  Reported by Faré Rideau on sbcl-devel.
+
+414: strange DISASSEMBLE warning
+
+  Compiling and disassembling 
+
+   (defun disassemble-source-form-bug (x y z)
+     (declare (optimize debug))
+     (list x y z))
+
+  Gives
+
+   WARNING: bogus form-number in form!  The source file has probably 
+   been changed too much to cope with.
+
+415: Issues creating large arrays on x86-64/Linux and x86/Darwin
+
+   (make-array (1- array-dimension-limit))
+
+   causes a GC invariant violation on x86-64/Linux, and
+   an unhandled SIGILL on x86/Darwin.
+
+416: backtrace confusion
+
+  (defun foo (x)
+    (let ((v "foo"))
+      (flet ((bar (z)
+               (oops v z)
+               (oops z v)))
+        (bar x)
+        (bar v))))
+  (foo 13)
+
+  gives the correct error, but the backtrace shows 
+    1: (SB-KERNEL:FDEFINITION-OBJECT 13 NIL)
+  as the second frame.
+
+418: SUBSEQ on lists doesn't support bignum indexes
+
+ LIST-SUBSEQ* now has all the works necessary to support bignum indexes,
+ but it needs to be verified that changing the DEFKNOWN doesn't kill
+ performance elsewhere.
+
+ Other generic sequence functions have this problem as well.