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

diff --git a/BUGS b/BUGS
index 503fdc4..4c64490 100644
--- a/BUGS
+++ b/BUGS
@@ -1612,22 +1612,6 @@ WORKAROUND:
   For some more details see comments for (define-alien-type-method
   (c-string :deport-gen) ...)  in host-c-call.lisp.
 
-402: "DECLAIM DECLARATION does not inform the PCL code-walker"
-  reported by Vincent Arkesteijn:
-
-  (declaim (declaration foo))
-  (defgeneric bar (x))
-  (defmethod bar (x)
-    (declare (foo x))
-    x)
-
-  ==> WARNING: The declaration FOO is not understood by
-      SB-PCL::SPLIT-DECLARATIONS.
-      Please put FOO on one of the lists SB-PCL::*NON-VAR-DECLARATIONS*,
-      SB-PCL::*VAR-DECLARATIONS-WITH-ARG*, or
-      SB-PCL::*VAR-DECLARATIONS-WITHOUT-ARG*.
-      (Assuming it is a variable declaration without argument).
-
 403: FORMAT/PPRINT-LOGICAL-BLOCK of CONDITIONs ignoring *PRINT-CIRCLE*
   In sbcl-0.9.13.34,
     (defparameter *c*
@@ -1729,6 +1713,10 @@ WORKAROUND:
 		3: (SB-C::BOUND-FUNC ...)
 		4: (SB-C::%SINGLE-FLOAT-DERIVE-TYPE-AUX ...)
 
+  These are now fixed, but (COERCE HUGE 'SINGLE-FLOAT) still signals a
+  type-error at runtime. The question is, should it instead signal a
+  floating-point overflow, or return an infinity?
+
 408: SUBTYPEP confusion re. OR of SATISFIES of not-yet-defined predicate
 	As reported by Levente M\'{e}sz\'{a}ros sbcl-devel 2006-02-20,
 		(aver (equal (multiple-value-list
@@ -1785,21 +1773,6 @@ WORKAROUND:
   implementation of read circularity, using a symbol as a marker for
   the previously-referenced object.
 
-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.
-
 415: Issues creating large arrays on x86-64/Linux and x86/Darwin
 
    (make-array (1- array-dimension-limit))