0.6.11.24:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 82e95d2..6857912 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -118,15 +118,6 @@ WORKAROUND:
          (during macroexpansion of IN-PACKAGE,
          during macroexpansion of DEFFOO)
 
-13:
-  Floating point infinities are screwed up. [When I was converting CMU CL
-  to SBCL, I was looking for complexity to delete, and I thought it was safe
-  to just delete support for floating point infinities. It wasn't: they're
-  generated by the floating point hardware even when we remove support
-  for them in software. Also we claim the :IEEE-FLOATING-POINT feature,
-  and I think that means we should support infinities.-- WHN] Support
-  for them should be restored.
-
 14:
   The ANSI syntax for non-STANDARD method combination types in CLOS is
        (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN))
@@ -825,12 +816,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   (I haven't tried to investigate this bug enough to guess whether
   there might be any user-level symptoms.)
 
-86:
-  The system doesn't know how to reduce
-    (specifier-type '(intersection (or number vector) real)),
-  it just ends up as a HAIRY-TYPE. Smarter INTERSECTION2 methods for
-  UNION-TYPE might help.
-
 87:
   Despite what the manual says, (DECLAIM (SPEED 0)) doesn't cause
   things to be byte compiled. This seems to be true in cmucl-2.4.19,
@@ -838,6 +823,14 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   but ordinary COMPILE-FILE of a file containing (DECLAIM (SPEED 0))
   does not.
 
+90: 
+  a latent cross-compilation/bootstrapping bug: The cross-compilation
+  host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp
+  and possibly elsewhere. Instead, we should use the target system's
+  CHAR-CODE-LIMIT. This will probably cause problems if we try to 
+  bootstrap on a system which uses a different value of CHAR-CODE-LIMIT
+  than SBCL does.
+
 
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER