X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=37156e8c6b107316a675feaf285252eda14a62f3;hb=6e7e59adb6f6c30f84b31695b48cb51e2c519d75;hp=14bfd66f743b64add181e252b889c85494102c55;hpb=a8f0175b16a00f5fc83eb8d8a718ae7fc5497514;p=sbcl.git

diff --git a/BUGS b/BUGS
index 14bfd66..37156e8 100644
--- a/BUGS
+++ b/BUGS
@@ -365,13 +365,6 @@ WORKAROUND:
   The implementation of #'+ returns its single argument without
   type checking, e.g. (+ "illegal") => "illegal".
 
-56:
-  Attempting to use COMPILE on something defined by DEFMACRO fails:
-	(DEFMACRO FOO (X) (CONS X X))
-	(COMPILE 'FOO)
-Error in function C::GET-LAMBDA-TO-COMPILE:
-   #<Closure Over Function "DEFUN (SETF MACRO-FUNCTION)" {480E21B1}> was defined in a non-null environment.
-
 58:
   (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL
   Note: I looked into fixing this in 0.6.11.15, but gave up. The
@@ -805,30 +798,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   type declarations are supposed to be treated as assertions unless
   SAFETY 0, so we should be getting a TYPE-ERROR.
 
-112:
-  reported by Martin Atzmueller 2001-06-25; taken from CMU CL bugs
-  collection; apparently originally reported by Bruno Haible
-    (in-package :cl-user)
-    ;;; From: Bruno Haible
-    ;;; Subject: scope of SPECIAL declarations
-    ;;; It seems CMUCL has a bug relating to the scope of SPECIAL
-    ;;; declarations.  I observe this with "CMU Common Lisp 18a x86-linux
-    ;;; 1.4.0 cvs".
-    (let ((x 0))
-      (declare (special x))
-      (let ((x 1))
-        (let ((y x))
-          (declare (special x)) y)))
-    ;;; Gives: 0 (this should return 1 according to CLHS)
-    (let ((x 0))
-      (declare (special x))
-      (let ((x 1))
-        (let ((y x) (x 5))
-          (declare (special x)) y)))
-    ;;; Gives: 1 (correct).
-  The reported results match what we get from the interpreter
-  in sbcl-0.6.12.42.
-
 113:
   reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
   collection:
@@ -1219,7 +1188,90 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   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 this 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.
+  in IR1-OPTIMIZE-BLOCK.
+
+
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
     These numbers were used for bugs related to the old IR1