0.6.11.40:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 30d25d5..ad30c7b 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -118,15 +118,6 @@ WORKAROUND:
          (during macroexpansion of IN-PACKAGE,
          during macroexpansion of DEFFOO)
 
          (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))
 14:
   The ANSI syntax for non-STANDARD method combination types in CLOS is
        (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN))

@@ -234,10 +225,12 @@ WORKAROUND:
 
 26:
   reported by Sam Steingold on the cmucl-imp mailing list 12 May 2000:
 
 26:
   reported by Sam Steingold on the cmucl-imp mailing list 12 May 2000:

-
-Also, there is another bug: `array-displacement' should return an array
-or nil as first value (as per ANSI CL), while CMUCL declares it as
-returning an array as first value always.
+    Also, there is another bug: `array-displacement' should return an
+    array or nil as first value (as per ANSI CL), while CMUCL declares
+    it as returning an array as first value always.
+  (Actually, I think the old CMU CL version in SBCL never returns NIL,
+  i.e. it's not just a declaration problem, but the definition doesn't
+  behave ANSIly.)

 
 27:
   Sometimes (SB-EXT:QUIT) fails with 
 
 27:
   Sometimes (SB-EXT:QUIT) fails with 

@@ -365,9 +358,7 @@ returning an array as first value always.
 45:
   a slew of floating-point-related errors reported by Peter Van Eynde
   on July 25, 2000:
 45:
   a slew of floating-point-related errors reported by Peter Van Eynde
   on July 25, 2000:

-       a: (SQRT -9.0) fails, because SB-KERNEL::COMPLEX-SQRT is undefined.
-          Similarly, COMPLEX-ASIN, COMPLEX-ACOS, COMPLEX-ACOSH, and others
-          aren't found.
+       a: (fixed in sbcl-0.6.11.25)

        b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and 
           should probably be 1.4012985e-45. In SBCL,
           (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller
        b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and 
           should probably be 1.4012985e-45. In SBCL,
           (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller

@@ -381,10 +372,7 @@ returning an array as first value always.
                (EXPT 10.0d0 1000)
           PVE's regression tests want them to raise errors. SBCL
           generates the infinities instead, which may or may not be
                (EXPT 10.0d0 1000)
           PVE's regression tests want them to raise errors. SBCL
           generates the infinities instead, which may or may not be

-          conforming behavior, but then blow it by being unable to
-          output the infinities, since support for infinities is generally
-          broken, and in particular SB-IMPL::OUTPUT-FLOAT-INFINITY is
-          undefined.
+          conforming behavior.

        d: (in section12.erg) various forms a la 
                (FLOAT 1 DOUBLE-FLOAT-EPSILON)
           don't give the right behavior.
        d: (in section12.erg) various forms a la 
                (FLOAT 1 DOUBLE-FLOAT-EPSILON)
           don't give the right behavior.

@@ -825,13 +813,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.)
 
   (I haven't tried to investigate this bug enough to guess whether
   there might be any user-level symptoms.)
 

-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,
-  too: (COMPILE-FILE .. :BYTE-COMPILE T) causes byte-compilation,
-  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
 90: 
   a latent cross-compilation/bootstrapping bug: The cross-compilation
   host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp

@@ -840,6 +821,87 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   bootstrap on a system which uses a different value of CHAR-CODE-LIMIT
   than SBCL does.
 
   bootstrap on a system which uses a different value of CHAR-CODE-LIMIT
   than SBCL does.
 

+91:
+  (subtypep '(or (integer -1 1)
+                 unsigned-byte)
+            '(or (rational -1 7)
+                 unsigned-byte
+                 (integer -1 1))) => NIL,T
+  An analogous problem with SINGLE-FLOAT and REAL types was fixed in 
+  sbcl-0.6.11.22, but some peculiarites of the RATIO type make it 
+  awkward to generalize the fix to INTEGER and RATIONAL. It's not 
+  clear what's the best fix. (See the "bug in type handling" discussion
+  on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.)
+
+93:
+  In sbcl-0.6.11.26, (COMPILE 'IN-HOST-COMPILATION-MODE) in
+  src/cold/shared.lisp doesn't correctly translate the
+  interpreted function
+    (defun in-host-compilation-mode (fn)
+      (let ((*features* (cons :sb-xc-host *features*))
+            ;; the CROSS-FLOAT-INFINITY-KLUDGE, as documented in
+            ;; base-target-features.lisp-expr:
+            (*shebang-features* (set-difference *shebang-features*
+                                                '(:sb-propagate-float-type
+                                                  :sb-propagate-fun-type))))
+        (with-additional-nickname ("SB-XC" "SB!XC")
+          (funcall fn))))
+  No error is reported by the compiler, but when the function is executed,
+  it causes an error
+    TYPE-ERROR in SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
+      (:LINUX :X86 :IEEE-FLOATING-POINT :SB-CONSTRAIN-FLOAT-TYPE :SB-TEST
+       :SB-INTERPRETER :SB-DOC :UNIX ...) is not of type SYMBOL.
+
+94a: 
+  Inconsistencies between derived and declared VALUES return types for
+  DEFUN aren't checked very well. E.g. the logic which successfully
+  catches problems like
+    (declaim (ftype (function (fixnum) float) foo))
+    (defun foo (x)
+      (declare (type integer x))
+      (values x)) ; wrong return type, detected, gives warning, good!
+  fails to catch
+    (declaim (ftype (function (t) (values t t)) bar))
+    (defun bar (x)
+      (values x)) ; wrong number of return values, no warning, bad!
+  The cause of this is seems to be that (1) the internal function 
+  VALUES-TYPES-EQUAL-OR-INTERSECT used to make the check handles its
+  arguments symmetrically, and (2) when the type checking code was
+  written back when when SBCL's code was still CMU CL, the intent
+  was that this case
+    (declaim (ftype (function (t) t) bar))
+    (defun bar (x)
+      (values x x)) ; wrong number of return values; should give warning?
+  not be warned for, because a two-valued return value is considered
+  to be compatible with callers who expects a single value to be
+  returned. That intent is probably not appropriate for modern ANSI
+  Common Lisp, but fixing this might be complicated because of other
+  divergences between auld-style and new-style handling of
+  multiple-VALUES types. (Some issues related to this were discussed
+  on cmucl-imp at some length sometime in 2000.)
+
+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.
+
+96:
+  The TRACE facility can't be used on some kinds of functions.
+  Basically, the breakpoint facility wasn incompletely implemented
+  in the X86 port of CMU CL, and we haven't fixed it in SBCL.
+
+97:
+  FRESH-LINE doesn't seem to work properly within pretty-printed
+  output. E.g. 
+    "~@<unhandled CONDITION (of type ~S): ~2I~_~A~:>~2%"
+  called on a CONDITION whose printer does
+    "~&~@<error in function ~S: ~3I~:_~?~:>"
+  gives two newlines between "unhandled CONDITION" and "error", when
+  (it at least seems as though) correct behavior would be to give one.
+

 
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER
 
 
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER