0.8.1.40:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 527b053..ad13ce5 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -84,24 +84,7 @@ WORKAROUND:
      an error may be signalled at read time and it would be good if
      SBCL did it.
 
      an error may be signalled at read time and it would be good if
      SBCL did it.
 

-  c: Reading of not initialized slot sometimes causes SEGV (for inline
-     accessors it is fixed, but out-of-line still do not perform type
-     check).
-
-  d:
-    (declaim (optimize (safety 3) (speed 1) (space 1)))
-    (defstruct foo
-      x y)
-    (defstruct (stringwise-foo (:include foo
-                                         (x "x" :type simple-string)
-                                         (y "y" :type simple-string))))
-    (defparameter *stringwise-foo*
-      (make-stringwise-foo))
-    (setf (foo-x *stringwise-foo*) 0)
-    (defun frob-stringwise-foo (sf)
-      (aref (stringwise-foo-x sf) 0))
-    (frob-stringwise-foo *stringwise-foo*)
-  SEGV.
+  d: (fixed in 0.8.1.5)

 
 7:
   The "compiling top-level form:" output ought to be condensed.
 
 7:
   The "compiling top-level form:" output ought to be condensed.

@@ -566,41 +549,6 @@ WORKAROUND:
 
   See also bugs #45.c and #183
 
 
   See also bugs #45.c and #183
 

-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.
-
-  (Python LET-converts KIDIFY1 into KID-FROB, then tries to inline
-  expand KID-FROB into %ZEEP. Having partially done it, it sees a call
-  of KIDIFY1, which already does not exist. So it gives up on
-  expansion, leaving garbage consisting of infinished blocks of the
-  partially converted function.)
-
-  (due to reordering of the compiler this example is compiled
-  successfully by 0.7.14, but the bug probably remains)
-

 162:
   (reported by Robert E. Brown 2002-04-16) 
   When a function is called with too few arguments, causing the
 162:
   (reported by Robert E. Brown 2002-04-16) 
   When a function is called with too few arguments, causing the

@@ -700,11 +648,9 @@ WORKAROUND:
   propagation or with SSA, but consider
 
     (let ((x 0))
   propagation or with SSA, but consider
 
     (let ((x 0))

-      (loop (if (random-boolean)
-                (incf x 2)
-                (incf x 5))))
+      (loop (incf x 2)))

 
 

-  The careful type of X is {2k+5n} :-(. Is it really important to be
+  The careful type of X is {2k} :-(. Is it really important to be

   able to work with unions of many intervals?
 
 190: "PPC/Linux pipe? buffer? bug"
   able to work with unions of many intervals?
 
 190: "PPC/Linux pipe? buffer? bug"

@@ -1062,33 +1008,95 @@ WORKAROUND:
 
   This is a problem because the compiler emits optimization notes when
   you use a non-simple array, and without a type specifier for hairy
 
   This is a problem because the compiler emits optimization notes when
   you use a non-simple array, and without a type specifier for hairy

-  array types, there's no good way to tell it you're doing it 
+  array types, there's no good way to tell it you're doing it

   intentionally so that it should shut up and just compile the code.
 
   intentionally so that it should shut up and just compile the code.
 

-258: "TYPE-ERROR when recursive LABELS function is declared INLINE"
-  The compiler does emit a helpful 
-    ; note: couldn't inline expand because expansion calls this 
-    ;   LET-converted local function:
-    ;   "LABELS COMMON-LISP-USER::C.FROB"
-  but still shouldn't fail with a TYPE-ERROR 
-    The value NIL is not of type SB-C::NODE.
-  when compiling
-    (cl:in-package :cl-user)
-    (declaim (optimize (safety 3) (speed 2) (space 1)))
-    (defvar *foo*)
-    (defvar *bar*)
-    (defun u-b-sra (x r ad0 &optional ad1 &rest ad-list)
-        (labels ((c.frob (c0)
-                   (let ()
-                     (when *foo*
-                       (vector-push-extend c0 *bar*))))
-                 (ad.frob (ad)
-                   (if *foo*
-                       (map nil #'ad.frob (the (vector t) *bar*))
-                       (dolist (b *bar*)
-                         (c.frob b)))))
-          (declare (inline c.frob ad.frob)) ; 'til DYNAMIC-EXTENT
-          (ad.frob ad0)))
+  Another problem is confusing error message "asserted type ARRAY
+  conflicts with derived type (VALUES SIMPLE-VECTOR &OPTIONAL)" during
+  compiling (LAMBDA (V) (VALUES (SVREF V 0) (VECTOR-POP V))).
+
+  The last problem is that when type assertions are converted to type
+  checks, types are represented with type specifiers, so we could lose
+  complex attribute. (Now this is probably not important, because
+  currently checks for complex arrays seem to be performed by
+  callees.)
+
+259:
+  (compile nil '(lambda () (aref (make-array 0) 0))) compiles without
+  warning.  Analogous cases with the index and length being equal and
+  greater than 0 are warned for; the problem here seems to be that the
+  type required for an array reference of this type is (INTEGER 0 (0))
+  which is canonicalized to NIL.
+
+260:
+  a.
+  (let* ((s (gensym))
+         (t1 (specifier-type s)))
+    (eval `(defstruct ,s))
+    (type= t1 (specifier-type s)))
+  => NIL, NIL
+
+  (fixed in 0.8.1.24)
+
+  b. The same for CSUBTYPEP.
+
+261:
+    * (let () (list (the (values &optional fixnum) (eval '(values)))))
+    debugger invoked on condition of type TYPE-ERROR:
+      The value NIL is not of type FIXNUM.
+
+262: "yet another bug in inline expansion of local functions"
+  Compiler fails on
+
+    (defun foo (x y)
+      (declare (integer x y))
+      (+ (block nil
+            (flet ((xyz (u)
+                     (declare (integer u))
+                     (if (> (1+ (the unsigned-byte u)) 0)
+                         (+ 1 u)
+                         (return (+ 38 (cos (/ u 78)))))))
+              (declare (inline xyz))
+              (return-from foo
+                (* (funcall (eval #'xyz) x)
+                   (if (> x 30)
+                       (funcall (if (> x 5) #'xyz #'identity)
+                                (+ x 13))
+                       38)))))
+         (sin (* x y))))
+
+  Urgh... It's time to write IR1-copier.
+
+262:
+  In 0.8.1.32:
+
+    * (ensure-generic-function 'foo)
+    #<STANDARD-GENERIC-FUNCTION FOO (0)>
+    * (defmethod foo (x) x)
+    debugger invoked on condition of type SIMPLE-ERROR:
+      The generic function #<STANDARD-GENERIC-FUNCTION FOO (0)> takes 0 required
+      arguments; was asked to find a method with specializers (#<BUILT-IN-CLASS T>)
+
+  AMOP seems to say that it should work (first ADD-METHOD initializes
+  GF lambda list).
+
+264:
+  (reported by <dsk> on #lisp 2003-07-16)
+
+    (progv '(foo) '(1)
+      (eval '(symbol-macrolet ((foo 3))
+               (declare (special foo))
+               foo)))
+
+  does not signal an error.
+
+  (fixed in 0.8.1.37)
+
+265:
+  SB-EXT:RUN-PROGRAM is currently non-functional on Linux/PPC;
+  attempting to use it leads to segmentation violations.  This is
+  probably because of a bogus implementation of
+  os_restore_fp_control().

 
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
 
 DEFUNCT CATEGORIES OF BUGS
   IR1-#: