0.9.7.22:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index df38981..7bbd84c 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -94,6 +94,9 @@ WORKAROUND:
   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.
 
   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.
 
+  Currently INSPECT and DESCRIBE do show the values, but showing the
+  names of the bindings would be even nicer.
+
 35:
   The compiler assumes that any time a function of declared FTYPE
   doesn't signal an error, its arguments were of the declared type.
 35:
   The compiler assumes that any time a function of declared FTYPE
   doesn't signal an error, its arguments were of the declared type.
@@ -195,19 +198,6 @@ WORKAROUND:
   holding... * is not equivalent to T in many cases, such as 
     (VECTOR *) /= (VECTOR T).
 
   holding... * is not equivalent to T in many cases, such as 
     (VECTOR *) /= (VECTOR T).
 
-95:
-  The facility for dumping a running Lisp image to disk gets confused
-  when run without the PURIFY option, and creates an unnecessarily large
-  core file (apparently representing memory usage up to the previous
-  high-water mark). Moreover, when the file is loaded, it confuses the
-  GC, so that thereafter memory usage can never be reduced below that
-  level.
-
-  (As of 0.8.7.3 it's likely that the latter half of this bug is fixed.
-  The interaction between gencgc and the variables used by
-  save-lisp-and-die is still nonoptimal, though, so no respite from
-  big core files yet)
-
 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
 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
@@ -888,17 +878,6 @@ WORKAROUND:
            (1+ *faa*))
      (faa 1d0) => type error
 
            (1+ *faa*))
      (faa 1d0) => type error
 
-278:
-  a.
-    (defun foo ()
-      (declare (optimize speed))
-      (loop for i of-type (integer 0) from 0 by 2 below 10
-            collect i))
-
-  uses generic arithmetic.
-
-  b. (fixed in 0.8.3.6)
-
 279: type propagation error -- correctly inferred type goes astray?
   In sbcl-0.8.3 and sbcl-0.8.1.47, the warning
        The binding of ABS-FOO is a (VALUES (INTEGER 0 0)
 279: type propagation error -- correctly inferred type goes astray?
   In sbcl-0.8.3 and sbcl-0.8.1.47, the warning
        The binding of ABS-FOO is a (VALUES (INTEGER 0 0)
@@ -1074,13 +1053,6 @@ WORKAROUND:
   around the same time regarding a call to LIST on sparc with 1000
   arguments) and other implementation limit constants.
 
   around the same time regarding a call to LIST on sparc with 1000
   arguments) and other implementation limit constants.
 
-311: "Tokeniser not thread-safe"
-    (see also Robert Marlow sbcl-help "Multi threaded read chucking a
-    spak" 2004-04-19)
-  The tokenizer's use of *read-buffer* and *read-buffer-length* causes
-  spurious errors should two threads attempt to tokenise at the same
-  time.
-
 314: "LOOP :INITIALLY clauses and scope of initializers"
   reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
   test suite, originally by Thomas F. Burdick.
 314: "LOOP :INITIALLY clauses and scope of initializers"
   reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
   test suite, originally by Thomas F. Burdick.
@@ -1124,20 +1096,6 @@ WORKAROUND:
     #(1 2 ((SB-IMPL::|,|) + 2 2) 4)
   which probably isn't intentional.
 
     #(1 2 ((SB-IMPL::|,|) + 2 2) 4)
   which probably isn't intentional.
 
-323: "REPLACE, BIT-BASH and large strings"
-  The transform for REPLACE on simple-base-strings uses BIT-BASH, which
-  at present has an upper limit in size.  Consequently, in sbcl-0.8.10
-    (defun foo ()
-      (declare (optimize speed (safety 1)))
-      (let ((x (make-string 140000000))
-            (y (make-string 140000000)))
-        (length (replace x y))))
-    (foo)
-  gives 
-    debugger invoked on a TYPE-ERROR in thread 2412:
-      The value 1120000000 is not of type (MOD 536870911).
-  (see also "more and better sequence transforms" sbcl-devel 2004-05-10)
-
 324: "STREAMs and :ELEMENT-TYPE with large bytesize"
   In theory, (open foo :element-type '(unsigned-byte <x>)) should work
   for all positive integral <x>.  At present, it only works for <x> up
 324: "STREAMs and :ELEMENT-TYPE with large bytesize"
   In theory, (open foo :element-type '(unsigned-byte <x>)) should work
   for all positive integral <x>.  At present, it only works for <x> up
@@ -1400,25 +1358,6 @@ WORKAROUND:
   method is applicable, and yet matches neither of the method group
   qualifier patterns.
 
   method is applicable, and yet matches neither of the method group
   qualifier patterns.
 
-341: PPRINT-LOGICAL-BLOCK / PPRINT-FILL / PPRINT-LINEAR sharing detection.
-  (from Paul Dietz' test suite)
-
-  CLHS on PPRINT-LINEAR and PPRINT-FILL (and PPRINT-TABULAR, though
-  that's slightly different) states that these functions perform
-  circular and shared structure detection on their object.  Therefore,
-
-  a.(let ((*print-circle* t))
-      (pprint-linear *standard-output* (let ((x '(a))) (list x x))))
-    should print "(#1=(A) #1#)"
-
-  b.(let ((*print-circle* t))
-      (pprint-linear *standard-output* 
-                     (let ((x (cons nil nil))) (setf (cdr x) x) x)))
-    should print "#1=(NIL . #1#)"
-
-  (it is likely that the fault lies in PPRINT-LOGICAL-BLOCK, as
-  suggested by the suggested implementation of PPRINT-TABULAR)
-
 343: MOP:COMPUTE-DISCRIMINATING-FUNCTION overriding causes error
   Even the simplest possible overriding of
   COMPUTE-DISCRIMINATING-FUNCTION, suggested in the PCL implementation
 343: MOP:COMPUTE-DISCRIMINATING-FUNCTION overriding causes error
   Even the simplest possible overriding of
   COMPUTE-DISCRIMINATING-FUNCTION, suggested in the PCL implementation
@@ -2006,12 +1945,6 @@ WORKAROUND:
  #.SB-EXT:SINGLE/DOUBLE-FLOAT-POSITIVE-INFINITY. These tests have been
  disabled on Darwin for now.
 
  #.SB-EXT:SINGLE/DOUBLE-FLOAT-POSITIVE-INFINITY. These tests have been
  disabled on Darwin for now.
 
-374: BIT-AND problem on ppc/darwin:
-  The BIT-AND test in bit-vector.impure-cload.lisp results in
-    fatal error encountered in SBCL pid 8356:
-    GC invariant lost, file "gc-common.c", line 605
-  on ppc/darwin. Test disabled for the duration.
-
 375: MISC.555
     (compile nil '(lambda (p1)
                    (declare (optimize (speed 1) (safety 2) (debug 2) (space 0))
 375: MISC.555
     (compile nil '(lambda (p1)
                    (declare (optimize (speed 1) (safety 2) (debug 2) (space 0))
@@ -2045,11 +1978,6 @@ WORKAROUND:
   arrange_return_to_lisp_function(), but this looked hard to do in
   general without suffering from memory leaks.
 
   arrange_return_to_lisp_function(), but this looked hard to do in
   general without suffering from memory leaks.
 
-378: floating-point exceptions not signalled on x86-64
-  Floating point traps are currently not enabled on the x86-64 port.
-  This is true for at least overflow detection (as tested in
-  float.pure.lisp) and divide-by-zero.
-
 379: TRACE :ENCAPSULATE NIL broken on ppc/darwin
   See commented-out test-case in debug.impure.lisp.
 
 379: TRACE :ENCAPSULATE NIL broken on ppc/darwin
   See commented-out test-case in debug.impure.lisp.
 
@@ -2077,3 +2005,101 @@ WORKAROUND:
   getting less ambitious about detecting shared list structure, or 
   implementing the moral equivalent of EQUAL hash tables in a 
   cycle-tolerant way.
   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 ()
+      (let ((x #.(make-array 4 :fill-pointer 0)))
+        (values (eval `(typep ',x 'simple-array))
+                (typep x 'simple-array))))
+  then (FOO) => T, NIL.
+
+  Similar problems exist with SIMPLE-ARRAY-P, ARRAY-HEADER accessors
+  and all array dimension functions.
+
+383: ASH'ing non-constant zeros
+  Compiling
+    (lambda (b)
+      (declare (type (integer -2 14) b))
+      (declare (ignorable b))
+      (ash (imagpart b) 57))
+  on PPC (and other platforms, presumably) gives an error during the
+  emission of FASH-ASH-LEFT/FIXNUM=>FIXNUM as the assembler attempts to
+  stuff a too-large constant into the immediate field of a PPC
+  instruction.  Either the VOP should be fixed or the compiler should be
+  taught how to transform this case away, paying particular attention
+  to side-effects that might occur in the arguments to ASH.
+
+384: Compiler runaway on very large character types
+
+  (compile nil '(lambda (x)
+                    (declare (type (member #\a 1) x))
+                    (the (member 1 nil) x)))
+
+  The types apparently normalize into a very large type, and the compiler
+  gets lost in REMOVE-DUPLICATES.  Perhaps the latter should use
+  a better algorithm (one based on hash tables, say) on very long lists
+  when :TEST has its default value?
+
+  A simpler example:
+
+  (compile nil '(lambda (x) (the (not (eql #\a)) x)))
+
+  (partially fixed in 0.9.3.1, but a better representation for these
+   types is needed.)
+
+385:
+  (format nil "~4,1F" 0.001) => "0.00" (should be " 0.0");
+  (format nil "~4,1@F" 0.001) => "+.00" (should be "+0.0").
+
+386: SunOS/x86 stack exhaustion handling broken
+  According to <http://alfa.s145.xrea.com/sbcl/solaris-x86.html>, the
+  stack exhaustion checking (implemented with a write-protected guard
+  page) does not work on SunOS/x86.
+
+387:
+  12:10 < jsnell> the package-lock test is basically due to a change in the test 
+                  behaviour when you install a handler for error around it. I 
+                  thought I'd disabled the test for now, but apparently that was 
+                  my imagination
+  12:19 < Xophe> jsnell: ah, I see the problem in the package-locks stuff
+  12:19 < Xophe> it's the same problem as we had with compiler-error conditions
+  12:19 < Xophe> the thing that's signalled up and down the stack is a subtype of
+                  ERROR, where it probably shouldn't be
+
+388:
+  (found by Dmitry Bogomolov)
+
+    (defclass foo () ((x :type (unsigned-byte 8))))
+    (defclass bar () ((x :type symbol)))
+    (defclass baz (foo bar) ())
+
+  causes error
+
+    SB-PCL::SPECIALIZER-APPLICABLE-USING-TYPE-P cannot handle the second argument
+    (UNSIGNED-BYTE 8).
+
+389:
+  (reported several times on sbcl-devel, by Rick Taube, Brian Rowe and
+  others)
+
+  ROUND-NUMERIC-BOUND assumes that float types always have a FORMAT
+  specifying whether they're SINGLE or DOUBLE.  This is true for types
+  computed by the type system itself, but the compiler type derivation
+  short-circuits this and constructs non-canonical types.  A temporary
+  fix was made to ROUND-NUMERIC-BOUND for the sbcl-0.9.6 release, but
+  the right fix is to remove the abstraction violation in the
+  compiler's type deriver.
+
+392: slot-accessor for subclass misses obsoleted superclass
+  (fixed in sbcl-0.9.7.9)
+
+393: Wrong error from methodless generic function
+    (DEFGENERIC FOO (X))
+    (FOO 1 2)
+  gives NO-APPLICABLE-METHOD rather than an argument count error.
+
+394: (SETF CLASS-NAME)/REINITIALIZE-INSTANCE bug
+    (found by PFD ansi-tests)
+  in sbcl-0.9.7.15, (SETF (CLASS-NAME <class>) 'NIL) causes
+  (FIND-CLASS NIL) to return a #<STANDARD-CLASS NIL>.