0.8.20.14:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index bd15399..e6de843 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -84,33 +84,12 @@ WORKAROUND:
 
   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.
 
-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.
@@ -156,10 +135,6 @@ WORKAROUND:
   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))
@@ -378,24 +353,6 @@ WORKAROUND:
    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,
@@ -930,6 +887,14 @@ WORKAROUND:
 
   (fixed in 0.8.2.51, but a test case would be good)
 
+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
+
 278:
   a.
     (defun foo ()
@@ -1169,16 +1134,6 @@ WORKAROUND:
     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.
@@ -1537,19 +1492,6 @@ WORKAROUND:
   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
@@ -1581,6 +1523,10 @@ WORKAROUND:
  (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.
@@ -1593,6 +1539,13 @@ WORKAROUND:
  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
@@ -1971,3 +1924,162 @@ WORKAROUND:
       (: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.
+
+373: profiling issues on ppc/darwin
+ The following bit from smoke.impure.lisp fails on ppc/darwin:
+    (progn
+      (defun profiled-fun ()
+        (random 1d0))
+      (profile profiled-fun)
+      (loop repeat 100000 do (profiled-fun))
+      (report))
+ dropping into the debugger with a TYPE-ERROR:
+    The value -1073741382 is not of type UNSIGNED-BYTE.
+ The test has been disabled on Darwin till the bug is fixed.
+
+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))
+                            (type keyword p1))
+                   (keywordp p1)))
+
+  fails on hairy type check in IR2.
+
+  1. KEYWORDP is MAYBE-INLINE expanded (before TYPEP-like
+     transformation could eliminate it).
+
+  2. From the only call of KEYWORDP the type of its argument is
+     derived to be KEYWORD.
+
+  2. Type check for P1 is generated; it uses KEYWORDP to perform the
+     check, and so references the local function; from the KEYWORDP
+     argument type new CAST to KEYWORD is generated. The compiler
+     loops forever.
+
+376: MISC.563
+  Type deriver for CONJUGATE thinks that it returns an object of the
+  same type as its argument, which is wrong for such types as (EQL
+  #C(1 2)).