0.7.1.24:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index e70a656..bdf4781 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -137,6 +137,8 @@ WORKAROUND:
        (defclass ccc () ())
        (setf (find-class 'ccc1) (find-class 'ccc))
        (defmethod zut ((c ccc1)) 123)
+  In sbcl-0.7.1.13, this gives an error, 
+       There is no class named CCC1.
   DTC's recommended workaround from the mailing list 3 Mar 2000:
        (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc))
 
@@ -1059,20 +1061,6 @@ WORKAROUND:
   arguments in FLET/LABELS: it might be an old Python bug which is 
   only exercised by the new arrangement of the SBCL compiler.)
 
-132:
-  Trying to compile 
-    (DEFUN FOO () (CATCH 0 (PRINT 1331)))
-  gives an error
-    #<SB-C:TN '0!1> is not valid as the second argument to VOP:
-      SB-C:MAKE-CATCH-BLOCK,
-    since the TN's primitive type SB-VM::POSITIVE-FIXNUM doesn't allow
-    any of the SCs allowed by the operand restriction:
-     (SB-VM::DESCRIPTOR-REG)
-  The (CATCH 0 ...) construct is bad style (because of unportability
-  of EQ testing of numbers) but it is legal, and shouldn't cause an
-  internal compiler error. (This error occurs in sbcl-0.6.13 and in
-  0.pre7.86.flaky7.14.)
-
 135:
   Ideally, uninterning a symbol would allow it, and its associated
   FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, 
@@ -1188,9 +1176,150 @@ WORKAROUND:
   upgraded to do so. (This doesn't seem to be a high priority
   conformance problem, since seems hard to construct useful code
   where it matters.)
-   
+
+146:
+  Floating point errors are reported poorly. E.g. on x86 OpenBSD
+  with sbcl-0.7.1, 
+       * (expt 2.0 12777)
+       debugger invoked on condition of type SB-KERNEL:FLOATING-POINT-EXCEPTION:
+         An arithmetic error SB-KERNEL:FLOATING-POINT-EXCEPTION was signalled.
+       No traps are enabled? How can this be?
+  It should be possible to be much more specific (overflow, division
+  by zero, etc.) and of course the "How can this be?" should be fixable.
+
+147:
+  (reported by Alexey Dejneka sbcl-devel 2002-01-28)
+  Compiling a file containing
+    (deftype digit () '(member #\1))
+    (defun parse-num (string ind)
+      (flet ((digs ()
+               (let (old-index)
+                 (if (and (< ind ind)
+                          (typep (char string ind) 'digit))
+                     nil))))))
+  in sbcl-0.7.1 causes the compiler to fail with
+    internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" 
+  This problem seems to have been introduced by the sbcl-0.pre7.* compiler
+  changes, since 0.pre7.73 and 0.6.13 don't suffer from it. A related
+  test case is
+    (defun parse-num (index)
+      (let (num x)
+        (flet ((digs ()
+                 (setq num index))
+               (z ()
+                 (let ()
+                   (setq x nil))))
+          (when (and (digs) (digs)) x))))
+  In sbcl-0.7.1, this second test case failed with the same
+    internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" 
+  After the APD patches in sbcl-0.7.1.2 (new consistency check in
+  TARGET-IF-DESIRABLE, plus a fix in meta-vmdef.lisp to keep the
+  new consistency check from failing routinely) this second test case
+  failed in FIND-IN-PHYSENV instead. Fixes in sbcl-0.7.1.3 (not
+  closing over unreferenced variables) made this second test case
+  compile without error, but the original test case still fails.
+  Another way to get rid of the DEFTYPE without changing the symptom
+  of the bug is
+    (defvar *ch*)
+    (defun parse-num (string ind)
+      (flet ((digs ()
+               (let ()
+                 (if (and (< ind ind)
+                         (sb-int:memq *ch* '(#\1)))
+                     nil))))))
+  In sbcl-0.7.1.3, this fails with
+    internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" 
+  The problem occurs while the inline expansion of MEMQ,
+  #<LAMBDA :%DEBUG-NAME "varargs entry point for SB-C::.ANONYMOUS.">
+  is being LET-converted after having its second REF deleted, leaving
+  it with only one entry in LEAF-REFS.
+  
+148:
+  In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file
+    (in-package :cl-user)
+    (defvar *thing*)
+    (defvar *zoom*)
+    (defstruct foo bar bletch)
+    (defun %zeep ()
+      (labels ((kidify1 (kid)
+                )
+               (kid-frob (kid)
+                 (if *thing*
+                    (setf sweptm
+                          (m+ (frobnicate kid)
+                                    sweptm))
+                   (kidify1 kid))))
+      (declare (inline kid-frob))
+      (map nil
+          #'kid-frob
+          (the simple-vector (foo-bar perd)))))
+  fails with
+    debugger invoked on condition of type TYPE-ERROR:
+      The value NIL is not of type SB-C::NODE.
+  The location of this failure has moved around as various related
+  issues were cleaned up. As of sbcl-0.7.1.9, it occurs in 
+  NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
+
+150:
+  In sbcl-0.7.1.15, compiling this code 
+    (let* ()
+      (flet ((wufn () (glorp table1 4.9)))
+        (gleep *uustk* #'wufn "#1" (list)))
+      (if (eql (lo foomax 3.2))
+          (values)
+          (error "not ~S" '(eql (lo foomax 3.2))))
+      (values))
+  causes a failure in SB-C::ADD-TEST-CONSTRAINTS:
+    The value NIL is not of type SB-C::CONTINUATION.
+  other notes:
+    * The problem appears to be tied to the way that EQL is given only
+      one argument, and goes away when we give EQL a second argument.
+    * CMU CL 18c has this problem too, exercised by 
+       (compile nil
+                '(lambda ()
+                    (let* ()
+                     (flet ((wufn () (glorp table1 4.9)))
+                       (gleep *uustk* #'wufn "#1" (list)))
+                     (if (eql (lo foomax 3.2))
+                         (values)
+                         (error "not ~S" '(eql (lo foomax 3.2))))
+                     (values))))
+
+151:
+  From the ANSI description of GET-DISPATCH-MACRO-CHARACTER, it
+  should return NIL when there is no definition, e.g.
+    (GET-DISPATCH-MACRO-CHARACTER #\# #\{) => NIL
+  Instead, in sbcl-0.7.1.17 it returns
+    #<FUNCTION "top level local call SB!IMPL::DISPATCH-CHAR-ERROR">
+
+152:
+  Undefined functions are supposed to be reported as UNDEFINED-FUNCTION
+  conditions, inheriting from CELL-ERROR. Instead sbcl-0.7.1.19 reports
+  them as TYPE-ERRORs (reporting the problem as something not being
+  coerceable to a function).
+
+153:
+  (essentially the same problem as a CMU CL bug reported by Martin
+  Cracauer on cmucl-imp 2002-02-19)
+  There is a hole in structure slot type checking. Compiling and LOADing
+    (declaim (optimize safety))
+    (defstruct foo
+      (bla 0 :type fixnum))
+    (defun f ()
+      (let ((foo (make-foo)))
+        (setf (foo-bla foo) '(1 . 1))
+        (format t "Is ~a of type ~a a cons? => ~a~%"
+                (foo-bla foo)
+                (type-of (foo-bla foo))
+                (consp (foo-bla foo)))))
+    (f)
+  should signal an error, but in sbcl-0.7.1.21 instead gives the output
+    Is (1 . 1) of type CONS a cons? => NIL
+  without signalling an error.
+
+
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
-    These numbers were used for bugs related to the old IR1
-    interpreter. The # values reached 6 before the category
-    was closed down.
\ No newline at end of file
+    These labels were used for bugs related to the old IR1 interpreter.
+    The # values reached 6 before the category was closed down.