0.9.12.10:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index b9e6f93..4b009c1 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -84,37 +84,19 @@ WORKAROUND:
 
   d: (fixed in 0.8.1.5)
 
 
   d: (fixed in 0.8.1.5)
 
-7:
-  The "compiling top-level form:" output ought to be condensed.
-  Perhaps any number of such consecutive lines ought to turn into a
-  single "compiling top-level forms:" line.
-
-19:
-  (I *think* this is a bug. It certainly seems like strange behavior. But
-  the ANSI spec is scary, dark, and deep.. -- WHN)
-    (FORMAT NIL  "~,1G" 1.4) => "1.    "
-    (FORMAT NIL "~3,1G" 1.4) => "1.    "
-
 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.
 
 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.
 
-32:
-  The printer doesn't report closures very well. This is true in 
-  CMU CL 18b as well:
-    (PRINT #'CLASS-NAME)
-  gives
-    #<Closure Over Function "DEFUN STRUCTURE-SLOT-ACCESSOR" {134D1A1}>
-  It would be nice to make closures have a settable name slot,
-  and make things like DEFSTRUCT and FLET, which create closures,
-  set helpful values into this slot.
-
 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.
 
 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.
 
+  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.
@@ -156,10 +138,6 @@ WORKAROUND:
   so they could be supported after all. Very likely 
   SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
 
   so they could be supported after all. Very likely 
   SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
 
-60:
-  The debugger LIST-LOCATIONS command doesn't work properly.
-  (How should it work properly?)
-
 61:
   Compiling and loading
     (DEFUN FAIL (X) (THROW 'FAIL-TAG X))
 61:
   Compiling and loading
     (DEFUN FAIL (X) (THROW 'FAIL-TAG X))
@@ -167,11 +145,11 @@ WORKAROUND:
   then requesting a BACKTRACE at the debugger prompt gives no information
   about where in the user program the problem occurred.
 
   then requesting a BACKTRACE at the debugger prompt gives no information
   about where in the user program the problem occurred.
 
-  (this is apparently mostly fixed on the SPARC and PPC architectures:
-  while giving the backtrace the system complains about "unknown
+  (this is apparently mostly fixed on the SPARC, PPC, and x86 architectures:
+  while giving the backtrace the non-x86 systems complains about "unknown
   source location: using block start", but apart from that the
   source location: using block start", but apart from that the
-  backtrace seems reasonable.  See tests/debug.impure.lisp for a test
-  case)
+  backtrace seems reasonable. On x86 this is masked by bug 353. See
+  tests/debug.impure.lisp for a test case)
 
 64:
   Using the pretty-printer from the command prompt gives funny
 
 64:
   Using the pretty-printer from the command prompt gives funny
@@ -220,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
@@ -378,24 +343,6 @@ WORKAROUND:
    a STYLE-WARNING for references to variables similar to locals might
    be a good thing.)
 
    a STYLE-WARNING for references to variables similar to locals might
    be a good thing.)
 
-125:
-   (as reported by Gabe Garza on cmucl-help 2001-09-21)
-       (defvar *tmp* 3)
-       (defun test-pred (x y)
-         (eq x y))
-       (defun test-case ()
-         (let* ((x *tmp*)
-                (func (lambda () x)))
-           (print (eq func func))
-           (print (test-pred func func))
-           (delete func (list func))))
-   Now calling (TEST-CASE) gives output
-     NIL
-     NIL
-     (#<FUNCTION {500A9EF9}>)
-   Evidently Python thinks of the lambda as a code transformation so
-   much that it forgets that it's also an object.
-
 135:
   Ideally, uninterning a symbol would allow it, and its associated
   FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
 135:
   Ideally, uninterning a symbol would allow it, and its associated
   FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
@@ -437,6 +384,10 @@ WORKAROUND:
   conformance problem, since seems hard to construct useful code
   where it matters.)
 
   conformance problem, since seems hard to construct useful code
   where it matters.)
 
+  [ partially fixed by CSR in 0.8.17.17 because of a PFD ansi-tests
+    report that (COMPLEX RATIO) was failing; still failing on types of
+    the form (AND NUMBER (SATISFIES REALP) (SATISFIES ZEROP)). ]
+
   b. (fixed in 0.8.3.43)
 
 146:
   b. (fixed in 0.8.3.43)
 
 146:
@@ -624,18 +575,6 @@ WORKAROUND:
 211: "keywords processing"
   a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
      number of keyword arguments.
 211: "keywords processing"
   a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
      number of keyword arguments.
-  e. Compiling
-
-      (flet ((foo (&key y) (list y)))
-        (list (foo :y 1 :y 2)))
-
-     issues confusing message
-
-       ; in: LAMBDA NIL
-       ;     (FOO :Y 1 :Y 2)
-       ;
-       ; caught STYLE-WARNING:
-       ;   The variable #:G15 is defined but never used.
 
 212: "Sequence functions and circular arguments"
   COERCE, MERGE and CONCATENATE go into an infinite loop when given
 
 212: "Sequence functions and circular arguments"
   COERCE, MERGE and CONCATENATE go into an infinite loop when given
@@ -714,15 +653,6 @@ WORKAROUND:
   (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not
   produce invalid code, but type checking is not accurate.)
 
   (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not
   produce invalid code, but type checking is not accurate.)
 
-233: bugs in constraint propagation
-  b.
-  (declaim (optimize (speed 2) (safety 3)))
-  (defun foo (x y)
-    (if (typep (prog1 x (setq x y)) 'double-float)
-        (+ x 1d0)
-        (+ x 2)))
-  (foo 1d0 5) => segmentation violation
-
 235: "type system and inline expansion"
   a.
   (declaim (ftype (function (cons) number) acc))
 235: "type system and inline expansion"
   a.
   (declaim (ftype (function (cons) number) acc))
@@ -781,6 +711,11 @@ WORKAROUND:
   (UNSIGNED-BYTE 8) will write to the stream one byte at a time,
   rather than writing the sequence in one go, leading to severe
   performance degradation.
   (UNSIGNED-BYTE 8) will write to the stream one byte at a time,
   rather than writing the sequence in one go, leading to severe
   performance degradation.
+  As of sbcl-0.9.0.36, this is solved for fd-streams, so is less of a
+  problem in practice.  (Fully fixing this would require adding a
+  ansi-stream-n-bout slot and associated methods to write a byte
+  sequence to ansi-stream, similar to the existing ansi-stream-sout
+  slot/functions.)
 
 243: "STYLE-WARNING overenthusiasm for unused variables"
   (observed from clx compilation)
 
 243: "STYLE-WARNING overenthusiasm for unused variables"
   (observed from clx compilation)
@@ -926,16 +861,13 @@ WORKAROUND:
 
   (fixed in 0.8.2.51, but a test case would be good)
 
 
   (fixed in 0.8.2.51, but a test case would be good)
 
-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)
+276:
+  b. The same as in a., but using MULTIPLE-VALUE-SETQ instead of SETQ.
+  c. (defvar *faa*)
+     (defmethod faa ((*faa* double-float))
+           (set '*faa* (when (< *faa* 0) (- *faa*)))
+           (1+ *faa*))
+     (faa 1d0) => type error
 
 279: type propagation error -- correctly inferred type goes astray?
   In sbcl-0.8.3 and sbcl-0.8.1.47, the warning
 
 279: type propagation error -- correctly inferred type goes astray?
   In sbcl-0.8.3 and sbcl-0.8.1.47, the warning
@@ -962,24 +894,6 @@ WORKAROUND:
 
  (see also bug 117)
 
 
  (see also bug 117)
 
-281: COMPUTE-EFFECTIVE-METHOD error signalling.
-  (slightly obscured by a non-0 default value for
-   SB-PCL::*MAX-EMF-PRECOMPUTE-METHODS*)
-  It would be natural for COMPUTE-EFFECTIVE-METHOD to signal errors
-  when it finds a method with invalid qualifiers.  However, it
-  shouldn't signal errors when any such methods are not applicable to
-  the particular call being evaluated, and certainly it shouldn't when
-  simply precomputing effective methods that may never be called.
-  (setf sb-pcl::*max-emf-precompute-methods* 0)
-  (defgeneric foo (x)
-    (:method-combination +)
-    (:method ((x symbol)) 1)
-    (:method + ((x number)) x))
-  (foo 1) -> ERROR, but should simply return 1
-
-  The issue seems to be that construction of a discriminating function
-  calls COMPUTE-EFFECTIVE-METHOD with methods that are not all applicable.
-
 283: Thread safety: libc functions
   There are places that we call unsafe-for-threading libc functions
   that we should find alternatives for, or put locks around.  Known or
 283: Thread safety: libc functions
   There are places that we call unsafe-for-threading libc functions
   that we should find alternatives for, or put locks around.  Known or
@@ -1048,14 +962,6 @@ WORKAROUND:
   the control word; however, this clobbers any change the user might
   have made.
 
   the control word; however, this clobbers any change the user might
   have made.
 
-296:
-  (reported by Adam Warner, sbcl-devel 2003-09-23)
-
-  The --load toplevel argument does not perform any sanitization of its
-  argument.  As a result, files with Lisp pathname pattern characters
-  (#\* or #\?, for instance) or quotation marks can cause the system
-  to perform arbitrary behaviour.
-
 297:
   LOOP with non-constant arithmetic step clauses suffers from overzealous
   type constraint: code of the form 
 297:
   LOOP with non-constant arithmetic step clauses suffers from overzealous
   type constraint: code of the form 
@@ -1104,17 +1010,6 @@ WORKAROUND:
 
   The problem is that both EVALs sequentially write to the same LVAR.
 
 
   The problem is that both EVALs sequentially write to the same LVAR.
 
-305:
-  (Reported by Dave Roberts.)
-  Local INLINE/NOTINLINE declaration removes local FTYPE declaration:
-
-    (defun quux (x)
-      (declare (ftype (function () (integer 0 10)) fee)
-               (inline fee))
-      (1+ (fee)))
-
-  uses generic arithmetic with INLINE and fixnum without.
-
 306: "Imprecise unions of array types"
   a.(defun foo (x)
       (declare (optimize speed)
 306: "Imprecise unions of array types"
   a.(defun foo (x)
       (declare (optimize speed)
@@ -1141,13 +1036,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.
@@ -1165,16 +1053,6 @@ WORKAROUND:
     Expected: (2 6 15 38)
     Got:      ERROR
 
     Expected: (2 6 15 38)
     Got:      ERROR
 
-317: "FORMAT of floating point numbers"
-  reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
-  test suite.
-    (format nil "~1F" 10) => "0." ; "10." expected
-    (format nil "~0F" 10) => "0." ; "10." expected
-    (format nil "~2F" 1234567.1) => "1000000." ; "1234567." expected
-  it would be nice if whatever fixed this also untangled the two
-  competing implementations of floating point printing (Steele and
-  White, and Burger and Dybvig) present in src/code/print.lisp
-
 318: "stack overflow in compiler warning with redefined class"
   reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
   test suite.
 318: "stack overflow in compiler warning with redefined class"
   reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
   test suite.
@@ -1201,20 +1079,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
@@ -1305,12 +1169,6 @@ WORKAROUND:
      in the wrapper, and then to update the instance just run through
      all the old wrappers in order from oldest to newest.
 
      in the wrapper, and then to update the instance just run through
      all the old wrappers in order from oldest to newest.
 
-331: "lazy creation of CLOS classes for user-defined conditions"
-    (defstruct foo)
-    (defstruct (bar (:include foo)))
-    (sb-mop:class-direct-subclasses (find-class 'foo))
-  returns NIL, rather than a singleton list containing the BAR class.
-
 332: "fasl stack inconsistency in structure redefinition"
   (reported by Tim Daly Jr sbcl-devel 2004-05-06)
   Even though structure redefinition is undefined by the standard, the
 332: "fasl stack inconsistency in structure redefinition"
   (reported by Tim Daly Jr sbcl-devel 2004-05-06)
   Even though structure redefinition is undefined by the standard, the
@@ -1483,32 +1341,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)
-
-342: PPRINT-TABULAR / PPRINT-LOGICAL-BLOCK logical block start position
-  The logical block introduced by PPRINT-LOGICAL-BLOCK should not
-  include the prefix, so that
-    (pprint-tabular *standard-output* '(1 2 3) t nil 2)
-  should print
-  "(1 2 3)" rather than "(1  2 3)".
-
 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
@@ -1542,32 +1374,10 @@ WORKAROUND:
   (Note: there's at least one dubious thing in room.lisp: see the
   comment in VALID-OBJ)
 
   (Note: there's at least one dubious thing in room.lisp: see the
   comment in VALID-OBJ)
 
-345: backtrace on x86 undefined function
-  In sbcl-0.8.13 (and probably earlier versions), code of the form
-    (flet ((test () (#:undefined-fun 42)))
-      (funcall #'test))
-  yields the debugger with a poorly-functioning backtrace.  Brian
-  Downing fixed most of the problems on non-x86 architectures, but on
-  the x86 the backtrace from this evaluation does not reveal anything
-  about the problem.  (See tests in debug.impure.lisp)
-
 346: alpha backtrace
   In sbcl-0.8.13, all backtraces from errors caused by internal errors
   on the alpha seem to have a "bogus stack frame".
 
 346: alpha backtrace
   In sbcl-0.8.13, all backtraces from errors caused by internal errors
   on the alpha seem to have a "bogus stack frame".
 
-348:
-  Structure slot setters do not preserve evaluation order:
-
-    (defstruct foo (x))
-
-    (let ((i (eval '-2))
-          (x (make-foo)))
-      (funcall #'(setf foo-x)
-               (incf i)
-               (aref (vector x) (incf i)))
-      (foo-x x))
-    => error
-
 349: PPRINT-INDENT rounding implementation decisions
   At present, pprint-indent (and indeed the whole pretty printer)
   more-or-less assumes that it's using a monospace font.  That's
 349: PPRINT-INDENT rounding implementation decisions
   At present, pprint-indent (and indeed the whole pretty printer)
   more-or-less assumes that it's using a monospace font.  That's
@@ -1579,5 +1389,762 @@ WORKAROUND:
   pprinter and only truncated at output?  (So that indenting by 1/2
   then 3/2 would indent by two spaces, not one?)
 
   pprinter and only truncated at output?  (So that indenting by 1/2
   then 3/2 would indent by two spaces, not one?)
 
-351: suboptimal error handling/reporting when compiling (PUSH (LET ...)) 
-  (fixed in 0.8.16.37)
+352: forward-referenced-class trouble
+ reported by Bruno Haible on sbcl-devel
+   (defclass c (a) ())
+   (setf (class-name (find-class 'a)) 'b)
+   (defclass a () (x))
+   (defclass b () (y))
+   (make-instance 'c)
+ Expected: an instance of c, with a slot named x
+ Got: debugger invoked on a SIMPLE-ERROR in thread 78906:
+        While computing the class precedence list of the class named C.
+        The class named B is a forward referenced class.
+        The class named B is a direct superclass of the class named C.
+
+353: debugger suboptimalities on x86
+ On x86 backtraces for undefined functions start with a bogus stack
+ frame, and  backtraces for throws to unknown catch tags with a "no 
+ debug information" frame. These are both due to CODE-COMPONENT-FROM-BITS
+ (used on non-x86 platforms) being a more complete solution then what
+ is done on x86.
+
+ On x86/linux large portions of tests/debug.impure.lisp have been commented
+ out as failures. The probable culprit for these problems is in x86-call-context
+ (things work fine on x86/freebsd).
+
+ More generally, the debugger internals suffer from excessive x86/non-x86
+ conditionalization and OAOOMization: refactoring the common parts would
+ be good.
+
+354: XEPs in backtraces
+ Under default compilation policy
+   (defun test ()
+     (throw :unknown t))
+   (test)
+ Has the XEP for TEST in the backtrace, not the TEST frame itself.
+ (sparc and x86 at least)
+
+ Since SBCL 0.8.20.1 this is hidden unless *SHOW-ENTRY-POINT-DETAILS*
+ is true (instead there appear two TEST frames at least on ppc). The
+ underlying cause seems to be that SB-C::TAIL-ANNOTATE will not merge
+ the tail-call for the XEP, since Python has by that time proved that
+ the function can never return; same happens if the function holds an
+ unconditional call to ERROR.
+
+355: change-class of generic-function
+    (reported by Bruno Haible)
+  The MOP doesn't support change-class on a generic-function. However, SBCL
+  apparently supports it, since it doesn't give an error or warning when doing
+  so so. Then, however, it produces wrong results for calls to this generic 
+  function.
+  ;;; The effective-methods cache:
+  (progn
+    (defgeneric testgf35 (x))
+    (defmethod testgf35 ((x integer))
+      (cons 'integer (if (next-method-p) (call-next-method))))
+    (defmethod testgf35 ((x real))
+      (cons 'real (if (next-method-p) (call-next-method))))
+    (defclass customized5-generic-function (standard-generic-function)
+      ()
+      (:metaclass sb-pcl:funcallable-standard-class))
+    (defmethod sb-pcl:compute-effective-method ((gf customized5-generic-function) method-combination methods)
+      `(REVERSE ,(call-next-method)))
+    (list
+      (testgf35 3)
+      (progn
+        (change-class #'testgf35 'customized5-generic-function)
+        (testgf35 3))))
+  Expected: ((INTEGER REAL) (REAL INTEGER))
+  Got:      ((INTEGER REAL) (INTEGER REAL))
+  ;;; The discriminating-function cache:
+  (progn
+    (defgeneric testgf36 (x))
+    (defmethod testgf36 ((x integer))
+      (cons 'integer (if (next-method-p) (call-next-method))))
+    (defmethod testgf36 ((x real))
+      (cons 'real (if (next-method-p) (call-next-method))))
+    (defclass customized6-generic-function (standard-generic-function)
+      ()
+      (:metaclass sb-pcl:funcallable-standard-class))
+    (defmethod sb-pcl:compute-discriminating-function ((gf customized6-generic-function))
+      (let ((orig-df (call-next-method)))
+        #'(lambda (&rest arguments)
+            (reverse (apply orig-df arguments)))))
+    (list
+      (testgf36 3)
+      (progn
+        (change-class #'testgf36 'customized6-generic-function)
+        (testgf36 3))))
+  Expected: ((INTEGER REAL) (REAL INTEGER))
+  Got:      ((INTEGER REAL) (INTEGER REAL))
+
+356: PCL corruption
+    (reported by Bruno Haible)
+  After the "layout depth conflict" error, the CLOS is left in a state where
+  it's not possible to define new standard-class subclasses any more.
+  Test case:
+  (defclass prioritized-dispatcher ()
+    ((dependents :type list :initform nil)))
+  (defmethod sb-pcl:validate-superclass ((c1 sb-pcl:funcallable-standard-class) 
+                                         (c2 (eql (find-class 'prioritized-dispatcher))))
+    t)
+  (defclass prioritized-generic-function (prioritized-dispatcher standard-generic-function)
+    ()
+    (:metaclass sb-pcl:funcallable-standard-class))
+  ;; ERROR, Quit the debugger with ABORT
+  (defclass typechecking-reader-class (standard-class)
+    ())
+  Expected: #<STANDARD-CLASS TYPECHECKING-READER-CLASS>
+  Got:      ERROR "The assertion SB-PCL::WRAPPERS failed."
+
+357: defstruct inheritance of initforms
+    (reported by Bruno Haible)
+  When defstruct and defclass (with :metaclass structure-class) are mixed,
+  1. some slot initforms are ignored by the DEFSTRUCT generated constructor
+     function, and 
+  2. all slot initforms are ignored by MAKE-INSTANCE. (This can be arguably
+     OK for initforms that were given in a DEFSTRUCT form, but for those
+     given in a DEFCLASS form, I think it qualifies as a bug.)
+  Test case:
+  (defstruct structure02a
+    slot1
+    (slot2 t)
+    (slot3 (floor pi)))
+  (defclass structure02b (structure02a)
+    ((slot4 :initform -44)
+     (slot5)
+     (slot6 :initform t)
+     (slot7 :initform (floor (* pi pi)))
+     (slot8 :initform 88))
+    (:metaclass structure-class))
+  (defstruct (structure02c (:include structure02b (slot8 -88)))
+    slot9 
+    (slot10 t)
+    (slot11 (floor (exp 3))))
+  ;; 1. Form:
+  (let ((a (make-structure02c)))
+    (list (structure02c-slot4 a)
+          (structure02c-slot5 a)
+          (structure02c-slot6 a)
+          (structure02c-slot7 a)))
+  Expected: (-44 nil t 9)
+  Got: (SB-PCL::..SLOT-UNBOUND.. SB-PCL::..SLOT-UNBOUND..
+        SB-PCL::..SLOT-UNBOUND.. SB-PCL::..SLOT-UNBOUND..)
+  ;; 2. Form:
+  (let ((b (make-instance 'structure02c)))
+    (list (structure02c-slot2 b)
+          (structure02c-slot3 b)
+          (structure02c-slot4 b)
+          (structure02c-slot6 b)
+          (structure02c-slot7 b)
+          (structure02c-slot8 b)
+          (structure02c-slot10 b)
+          (structure02c-slot11 b)))
+  Expected: (t 3 -44 t 9 -88 t 20)
+  Got: (0 0 0 0 0 0 0 0)
+
+358: :DECLARE argument to ENSURE-GENERIC-FUNCTION 
+    (reported by Bruno Haible)
+  According to ANSI CL, ensure-generic-function must accept a :DECLARE
+  keyword argument. In SBCL 0.8.16 it does not.
+  Test case:
+  (progn
+    (ensure-generic-function 'foo113 :declare '((optimize (speed 3))))
+    (sb-pcl:generic-function-declarations #'foo113))
+  Expected: ((OPTIMIZE (SPEED 3)))
+  Got: ERROR
+    Invalid initialization argument:
+      :DECLARE
+    in call for class #<SB-MOP:FUNCALLABLE-STANDARD-CLASS STANDARD-GENERIC-FUNCTION>.
+  See also:
+    The ANSI Standard, Section 7.1.2
+
+  Bruno notes: The MOP specifies that ensure-generic-function accepts :DECLARATIONS.
+  The easiest way to be compliant to both specs is to accept both (exclusively
+  or cumulatively).
+
+359: wrong default value for ensure-generic-function's :generic-function-class argument
+    (reported by Bruno Haible)
+  ANSI CL is silent on this, but the MOP's specification of ENSURE-GENERIC-FUNCTION says:
+   "The remaining arguments are the complete set of keyword arguments
+    received by ENSURE-GENERIC-FUNCTION."
+  and the spec of ENSURE-GENERIC-FUNCTION-USING-CLASS:
+   ":GENERIC-FUNCTION-CLASS - a class metaobject or a class name. If it is not
+    supplied, it defaults to the class named STANDARD-GENERIC-FUNCTION."
+  This is not the case in SBCL. Test case:
+   (defclass my-generic-function (standard-generic-function)
+     ()
+     (:metaclass sb-pcl:funcallable-standard-class))
+   (setf (fdefinition 'foo1)
+         (make-instance 'my-generic-function :name 'foo1))
+   (ensure-generic-function 'foo1
+     :generic-function-class (find-class 'standard-generic-function))
+   (class-of #'foo1)
+   ; => #<SB-MOP:FUNCALLABLE-STANDARD-CLASS STANDARD-GENERIC-FUNCTION>
+   (setf (fdefinition 'foo2)
+         (make-instance 'my-generic-function :name 'foo2))
+   (ensure-generic-function 'foo2)
+   (class-of #'foo2)
+  Expected: #<SB-MOP:FUNCALLABLE-STANDARD-CLASS STANDARD-GENERIC-FUNCTION>
+  Got:      #<SB-MOP:FUNCALLABLE-STANDARD-CLASS MY-GENERIC-FUNCTION>
+
+360: CALL-METHOD not recognized in method-combination body
+  (reported by Bruno Haible)
+  This method combination, which adds 'redo' and 'return' restarts for each
+  method invocation to standard method combination, gives an error in SBCL.
+  (defun prompt-for-new-values ()
+    (format *debug-io* "~&New values: ")
+    (list (read *debug-io*)))
+  (defun add-method-restarts (form method)
+    (let ((block (gensym))
+          (tag (gensym)))
+      `(BLOCK ,block
+         (TAGBODY
+           ,tag
+           (RETURN-FROM ,block
+             (RESTART-CASE ,form
+               (METHOD-REDO ()
+                 :REPORT (LAMBDA (STREAM) (FORMAT STREAM "Try calling ~S again." ,method))
+                 (GO ,tag))
+               (METHOD-RETURN (L)
+                 :REPORT (LAMBDA (STREAM) (FORMAT STREAM "Specify return values for ~S call." ,method))
+                 :INTERACTIVE (LAMBDA () (PROMPT-FOR-NEW-VALUES))
+                 (RETURN-FROM ,block (VALUES-LIST L)))))))))
+  (defun convert-effective-method (efm)
+    (if (consp efm)
+      (if (eq (car efm) 'CALL-METHOD)
+        (let ((method-list (third efm)))
+          (if (or (typep (first method-list) 'method) (rest method-list))
+            ; Reduce the case of multiple methods to a single one.
+            ; Make the call to the next-method explicit.
+            (convert-effective-method
+              `(CALL-METHOD ,(second efm)
+                 ((MAKE-METHOD
+                    (CALL-METHOD ,(first method-list) ,(rest method-list))))))
+            ; Now the case of at most one method.
+            (if (typep (second efm) 'method)
+              ; Wrap the method call in a RESTART-CASE.
+              (add-method-restarts
+                (cons (convert-effective-method (car efm))
+                      (convert-effective-method (cdr efm)))
+                (second efm))
+              ; Normal recursive processing.
+              (cons (convert-effective-method (car efm))
+                    (convert-effective-method (cdr efm))))))
+        (cons (convert-effective-method (car efm))
+              (convert-effective-method (cdr efm))))
+      efm))
+  (define-method-combination standard-with-restarts ()
+         ((around (:around))
+          (before (:before))
+          (primary () :required t)
+          (after (:after)))
+    (flet ((call-methods-sequentially (methods)
+             (mapcar #'(lambda (method)
+                         `(CALL-METHOD ,method))
+                     methods)))
+      (let ((form (if (or before after (rest primary))
+                    `(MULTIPLE-VALUE-PROG1
+                       (PROGN
+                         ,@(call-methods-sequentially before)
+                         (CALL-METHOD ,(first primary) ,(rest primary)))
+                       ,@(call-methods-sequentially (reverse after)))
+                    `(CALL-METHOD ,(first primary)))))
+        (when around
+          (setq form
+                `(CALL-METHOD ,(first around)
+                              (,@(rest around) (MAKE-METHOD ,form)))))
+        (convert-effective-method form))))
+  (defgeneric testgf16 (x) (:method-combination standard-with-restarts))
+  (defclass testclass16a () ())
+  (defclass testclass16b (testclass16a) ())
+  (defclass testclass16c (testclass16a) ())
+  (defclass testclass16d (testclass16b testclass16c) ())
+  (defmethod testgf16 ((x testclass16a))
+    (list 'a
+          (not (null (find-restart 'method-redo)))
+          (not (null (find-restart 'method-return)))))
+  (defmethod testgf16 ((x testclass16b))
+    (cons 'b (call-next-method)))
+  (defmethod testgf16 ((x testclass16c))
+    (cons 'c (call-next-method)))
+  (defmethod testgf16 ((x testclass16d))
+    (cons 'd (call-next-method)))
+  (testgf16 (make-instance 'testclass16d))
+
+  Expected: (D B C A T T)
+  Got: ERROR CALL-METHOD outside of a effective method form
+
+  This is a bug because ANSI CL HyperSpec/Body/locmac_call-m__make-method
+  says
+   "The macro call-method invokes the specified method, supplying it with
+    arguments and with definitions for call-next-method and for next-method-p.
+    If the invocation of call-method is lexically inside of a make-method,
+    the arguments are those that were supplied to that method. Otherwise
+    the arguments are those that were supplied to the generic function."
+  and the example uses nothing more than these two cases (as you can see by
+  doing (trace convert-effective-method)).
+
+361: initialize-instance of standard-reader-method ignores :function argument
+    (reported by Bruno Haible)
+  Pass a custom :function argument to initialize-instance of a
+  standard-reader-method instance, but it has no effect.
+  ;; Check that it's possible to define reader methods that do typechecking.
+  (progn
+    (defclass typechecking-reader-method (sb-pcl:standard-reader-method)
+      ())
+    (defmethod initialize-instance ((method typechecking-reader-method) &rest initargs
+                                    &key slot-definition)
+      (let ((name (sb-pcl:slot-definition-name slot-definition))
+            (type (sb-pcl:slot-definition-type slot-definition)))
+        (apply #'call-next-method method
+               :function #'(lambda (args next-methods)
+                             (declare (ignore next-methods))
+                             (apply #'(lambda (instance)
+                                        (let ((value (slot-value instance name)))
+                                          (unless (typep value type)
+                                            (error "Slot ~S of ~S is not of type ~S: ~S"
+                                                   name instance type value))
+                                          value))
+                                    args))
+               initargs)))
+    (defclass typechecking-reader-class (standard-class)
+      ())
+    (defmethod sb-pcl:validate-superclass ((c1 typechecking-reader-class) (c2 standard-class))
+      t)
+    (defmethod reader-method-class ((class typechecking-reader-class) direct-slot &rest args)
+      (find-class 'typechecking-reader-method))
+    (defclass testclass25 ()
+      ((pair :type (cons symbol (cons symbol null)) :initarg :pair :accessor testclass25-pair))
+      (:metaclass typechecking-reader-class))
+   (macrolet ((succeeds (form)
+                 `(not (nth-value 1 (ignore-errors ,form)))))
+      (let ((p (list 'abc 'def))
+            (x (make-instance 'testclass25)))
+        (list (succeeds (make-instance 'testclass25 :pair '(seventeen 17)))
+              (succeeds (setf (testclass25-pair x) p))
+              (succeeds (setf (second p) 456))
+              (succeeds (testclass25-pair x))
+              (succeeds (slot-value x 'pair))))))
+  Expected: (t t t nil t)
+  Got:      (t t t t t)
+
+  (inspect (first (sb-pcl:generic-function-methods #'testclass25-pair)))
+  shows that the method was created with a FAST-FUNCTION slot but with a
+  FUNCTION slot of NIL.
+
+362: missing error when a slot-definition is created without a name
+    (reported by Bruno Haible)
+  The MOP says about slot-definition initialization:
+  "The :NAME argument is a slot name. An ERROR is SIGNALled if this argument
+   is not a symbol which can be used as a variable name. An ERROR is SIGNALled
+   if this argument is not supplied."
+  Test case:
+   (make-instance (find-class 'sb-pcl:standard-direct-slot-definition))
+  Expected: ERROR
+  Got: #<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION NIL>
+
+363: missing error when a slot-definition is created with a wrong documentation object
+    (reported by Bruno Haible)
+  The MOP says about slot-definition initialization:
+  "The :DOCUMENTATION argument is a STRING or NIL. An ERROR is SIGNALled
+   if it is not. This argument default to NIL during initialization."
+  Test case:
+   (make-instance (find-class 'sb-pcl:standard-direct-slot-definition)
+                  :name 'foo
+                  :documentation 'not-a-string)
+  Expected: ERROR
+  Got: #<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION FOO>
+
+364: does not support class objects as specializer names
+   (reported by Bruno Haible)
+  According to ANSI CL 7.6.2, class objects are valid specializer names,
+  and "Parameter specializer names are used in macros intended as the
+  user-level interface (defmethod)". DEFMETHOD's syntax section doesn't
+  mention this possibility in the BNF for parameter-specializer-name;
+  however, this appears to be an editorial omission, since the CLHS
+  mentions issue CLASS-OBJECT-SPECIALIZER:AFFIRM as being approved
+  by X3J13. SBCL doesn't support it:
+   (defclass foo () ())
+   (defmethod goo ((x #.(find-class 'foo))) x)
+  Expected: #<STANDARD-METHOD GOO (#<STANDARD-CLASS FOO>)>
+  Got:      ERROR "#<STANDARD-CLASS FOO> is not a legal class name."
+
+365: mixin on generic-function subclass
+    (reported by Bruno Haible)
+  a mixin class
+    (defclass prioritized-dispatcher ()
+      ((dependents :type list :initform nil)))
+  on a generic-function subclass:
+    (defclass prioritized-generic-function (prioritized-dispatcher standard-generic-function)
+      ()
+      (:metaclass sb-pcl:funcallable-standard-class))
+  SBCL gives an error on this, telling to define a method on SB-MOP:VALIDATE-SUPERCLASS. If done,
+    (defmethod sb-pcl:validate-superclass ((c1 sb-pcl:funcallable-standard-class) 
+                                           (c2 (eql (find-class 'prioritized-dispatcher))))
+      t)
+  then, however,
+    (defclass prioritized-generic-function (prioritized-dispatcher standard-generic-function)
+      ()
+      (:metaclass sb-pcl:funcallable-standard-class))
+  => debugger invoked on a SIMPLE-ERROR in thread 6687:
+    layout depth conflict: #(#<SB-KERNEL:LAYOUT for T {500E1E9}> ...)
+  Further discussion on this: http://thread.gmane.org/gmane.lisp.steel-bank.general/491
+
+366: cannot define two generic functions with user-defined class
+   (reported by Bruno Haible)
+  it is possible to define one generic function class and an instance
+  of it. But attempting to do the same thing again, in the same session,
+  leads to a "Control stack exhausted" error. Test case:
+    (defclass my-generic-function-1 (standard-generic-function)
+      ()
+      (:metaclass sb-pcl:funcallable-standard-class))
+    (defgeneric testgf-1 (x) (:generic-function-class my-generic-function-1)
+      (:method ((x integer)) (cons 'integer nil)))
+    (defclass my-generic-function-2 (standard-generic-function)
+      ()
+      (:metaclass sb-pcl:funcallable-standard-class))
+    (defgeneric testgf-2 (x) (:generic-function-class my-generic-function-2)
+      (:method ((x integer)) (cons 'integer nil)))
+  => SB-KERNEL::CONTROL-STACK-EXHAUSTED
+
+367: TYPE-ERROR at compile time, undetected TYPE-ERROR at runtime
+  This test program
+    (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1)))
+    (defstruct e367)
+    (defstruct i367)
+    (defstruct g367
+      (i367s (make-array 0 :fill-pointer t) :type (or (vector i367) null)))
+    (defstruct s367
+      (g367 (error "missing :G367") :type g367 :read-only t))
+    ;;; In sbcl-0.8.18, commenting out this (DECLAIM (FTYPE ... R367))
+    ;;; gives an internal error at compile time:
+    ;;;    The value #<SB-KERNEL:NAMED-TYPE NIL> is not of
+    ;;;    type SB-KERNEL:VALUES-TYPE.
+    (declaim (ftype (function ((vector i367) e367) (or s367 null)) r367))
+    (declaim (ftype (function ((vector e367)) (values)) h367))
+    (defun frob (v w)
+      (let ((x (g367-i367s (make-g367))))
+        (let* ((y (or (r367 x w)
+                      (h367 x)))
+               (z (s367-g367 y)))
+          (format t "~&Y=~S Z=~S~%" y z)
+          (g367-i367s z))))
+    (defun r367 (x y) (declare (ignore x y)) nil)
+    (defun h367 (x) (declare (ignore x)) (values))
+    ;;; In sbcl-0.8.18, executing this form causes an low-level error
+    ;;;   segmentation violation at #X9B0E1F4
+    ;;; (instead of the TYPE-ERROR that one might like).
+    (frob 0 (make-e367))
+  can be made to cause two different problems, as noted in the comments:
+    bug 367a: Compile and load the file. No TYPE-ERROR is signalled at 
+      run time (in the (S367-G367 Y) form of FROB, when Y is NIL 
+      instead of an instance of S367). Instead (on x86/Linux at least)
+      we end up with a segfault.
+    bug 367b: Comment out the (DECLAIM (FTYPE ... R367)), and compile 
+      the file. The compiler fails with TYPE-ERROR at compile time.
+
+368: miscompiled OR (perhaps related to bug 367)
+  Trying to relax type declarations to find a workaround for bug 367,
+  it turns out that even when the return type isn't declared (or 
+  declared to be T, anyway) the system remains confused about type 
+  inference in code similar to that for bug 367:
+    (in-package :cl-user)
+    (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1)))
+    (defstruct e368)
+    (defstruct i368)
+    (defstruct g368
+      (i368s (make-array 0 :fill-pointer t) :type (or (vector i368) null)))
+    (defstruct s368
+      (g368 (error "missing :G368") :type g368 :read-only t))
+    (declaim (ftype (function (fixnum (vector i368) e368) t) r368))
+    (declaim (ftype (function (fixnum (vector e368)) t) h368))
+    (defparameter *h368-was-called-p* nil)
+    (defun nsu (vertices e368)
+      (let ((i368s (g368-i368s (make-g368))))
+        (let ((fuis (r368 0 i368s e368)))
+          (format t "~&FUIS=~S~%" fuis)
+          (or fuis (h368 0 i368s)))))
+    (defun r368 (w x y)
+      (declare (ignore w x y))
+      nil)
+    (defun h368 (w x)
+      (declare (ignore w x))
+      (setf *h368-was-called-p* t)
+      (make-s368 :g368 (make-g368)))
+    (trace r368 h368)
+    (format t "~&calling NSU~%")
+    (let ((nsu (nsu #() (make-e368))))
+      (format t "~&NSU returned ~S~%" nsu)
+      (format t "~&*H368-WAS-CALLED-P*=~S~%" *h368-was-called-p*)
+      (assert (s368-p nsu))
+      (assert *h368-was-called-p*))
+  In sbcl-0.8.18, both ASSERTs fail, and (DISASSEMBLE 'NSU) shows
+  that no call to H368 is compiled.
+
+369: unlike-an-intersection behavior of VALUES-TYPE-INTERSECTION
+  In sbcl-0.8.18.2, the identity $(x \cap y \cap y)=(x \cap y)$ 
+  does not hold for VALUES-TYPE-INTERSECTION, even for types which
+  can be intersected exactly, so that ASSERTs fail in this test case:
+    (in-package :cl-user)
+    (let ((types (mapcar #'sb-c::values-specifier-type 
+                         '((values (vector package) &optional)
+                           (values (vector package) &rest t)
+                           (values (vector hash-table) &rest t)
+                           (values (vector hash-table) &optional)
+                           (values t &optional)
+                           (values t &rest t)
+                           (values nil &optional)
+                           (values nil &rest t)
+                           (values sequence &optional)
+                           (values sequence &rest t)
+                           (values list &optional)
+                           (values list &rest t)))))
+       (dolist (x types)
+         (dolist (y types)
+           (let ((i (sb-c::values-type-intersection x y)))
+             (assert (sb-c::type= i (sb-c::values-type-intersection i x)))
+             (assert (sb-c::type= i (sb-c::values-type-intersection i y)))))))
+
+370: reader misbehaviour on large-exponent floats
+    (read-from-string "1.0s1000000000000000000000000000000000000000")
+  causes the reader to attempt to create a very large bignum (which it
+  will then attempt to coerce to a rational).  While this isn't
+  completely wrong, it is probably not ideal -- checking the floating
+  point control word state and then returning the relevant float
+  (most-positive-short-float or short-float-infinity) or signalling an
+  error immediately would seem to make more sense.
+
+372: floating-point overflow not signalled on ppc/darwin
+ The following assertions in float.pure.lisp fail on ppc/darwin 
+ (Mac OS X version 10.3.7):
+   (assert (raises-error? (scale-float 1.0 most-positive-fixnum)
+                         floating-point-overflow))
+   (assert (raises-error? (scale-float 1.0d0 (1+ most-positive-fixnum))
+                          floating-point-overflow)))
+ as the SCALE-FLOAT just returns 
+ #.SB-EXT:SINGLE/DOUBLE-FLOAT-POSITIVE-INFINITY. These tests have been
+ disabled on Darwin for now.
+
+377: Memory fault error reporting
+  On those architectures where :C-STACK-IS-CONTROL-STACK is in
+  *FEATURES*, we handle SIG_MEMORY_FAULT (SEGV or BUS) on an altstack,
+  so we cannot handle the signal directly (as in interrupt_handle_now())
+  in the case when the signal comes from some external agent (the user
+  using kill(1), or a fault in some foreign code, for instance).  As
+  of sbcl-0.8.20.20, this is fixed by calling
+  arrange_return_to_lisp_function() to a new error-signalling
+  function, but as a result the error reporting is poor: we cannot
+  even tell the user at which address the fault occurred.  We should
+  arrange such that arguments can be passed to the function called from
+  arrange_return_to_lisp_function(), but this looked hard to do in
+  general without suffering from memory leaks.
+
+379: TRACE :ENCAPSULATE NIL broken on ppc/darwin
+  See commented-out test-case in debug.impure.lisp.
+
+380: Accessor redefinition fails because of old accessor name
+  When redefining an accessor, SB-PCL::FIX-SLOT-ACCESSORS may try to
+  find the generic function named by the old accessor name using
+  ENSURE-GENERIC-FUNCTION and then remove the old accessor's method in
+  the GF. If the old name does not name a function, or if the old name
+  does not name a generic function, no attempt to find the GF or remove
+  any methods is made.
+
+  However, if an unrelated GF with an incompatible lambda list exists,
+  the class redefinition will fail when SB-PCL::REMOVE-READER-METHOD
+  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 ()
+      (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.
+
+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>.
+
+395: Unicode and streams
+  One of the remaining problems in SBCL's Unicode support is the lack
+  of generality in certain streams.
+  a. FILL-POINTER-STREAMs: SBCL refuses to write (e.g. using FORMAT)
+     to streams made from strings that aren't character strings with
+     fill-pointers:
+       (let ((v (make-array 5 :fill-pointer 0 :element-type 'standard-char)))
+         (format v "foo")
+         v)
+     should return a non-simple base string containing "foo" but
+     instead errors.
+
+     (reported on sbcl-help by "tichy")
+
+396: block-compilation bug
+    (let ((x 1))
+      (dotimes (y 10)
+        (let ((y y))
+          (when (funcall (eval #'(lambda (x) (eql x 2))) y)
+            (defun foo (z)
+              (incf x (incf y z))))))
+      (defun bar (z)
+        (foo z)
+        (values x)))
+  (bar 1) => 11, should be 4.
+
+397: SLEEP accuracy
+  The more interrupts arrive the less accurate SLEEP's timing gets.
+    (time (sb-thread:terminate-thread
+            (prog1 (sb-thread:make-thread (lambda ()
+                                            (loop
+                                             (princ #\!)
+                                             (force-output)
+                                             (sb-ext:gc))))
+              (sleep 1))))
+
+398: GC-unsafe SB-ALIEN string deporting
+  Translating a Lisp string to an alien string by taking a SAP to it
+  as done by the :DEPORT-GEN methods for C-STRING and UTF8-STRING
+  is not safe, since the Lisp string can move. For example the
+  following code will fail quickly on both cheneygc and pre-0.9.8.19
+  GENCGC: 
+
+  (setf (bytes-consed-between-gcs) 4096)
+  (define-alien-routine "strcmp" int (s1 c-string) (s2 c-string))
+     
+  (loop
+    (let ((string "hello, world"))
+       (assert (zerop (strcmp string string)))))
+     
+  (This will appear to work on post-0.9.8.19 GENCGC, since
+   the GC no longer zeroes memory immediately after releasing
+   it after a minor GC. Either enabling the READ_PROTECT_FREE_PAGES
+   #define in gencgc.c or modifying the example so that a major
+   GC will occasionally be triggered would unmask the bug.)
+
+  On cheneygc the only solution would seem to be allocating some alien
+  memory, copying the data over, and arranging that it's freed once we
+  return. For GENCGC we could instead try to arrange that the string
+  from which the SAP is taken is always pinned.
+
+  For some more details see comments for (define-alien-type-method
+  (c-string :deport-gen) ...)  in host-c-call.lisp.
+
+401: "optimizer runaway on bad constant type specifiers in TYPEP"
+  In 0.9.12.3 (and probably many earlier versions), COMPILE-FILE on
+    (defun ouch401 ()
+      (etypecase (signum (- x y))
+        ((-1 nil))
+         ((0 1) (oops "shouldn't happen"))))
+  or just
+    (defun foo401 (x)
+      (typep x '(-1 nil)))
+  spins emitting what seems to be an endless series of compiler 
+  warnings like
+    ; --> TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP 
+    ; --> TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP 
+    ; --> TYPEP 
+    ; ==>
+    ;   (TYPEP SB-C::OBJECT '(-1 NIL))
+    ; 
+    ; caught WARNING:
+    ;   illegal type specifier for TYPEP: (-1 NIL)