0.8.2.55:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 171061e..84357b1 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.

@@ -117,12 +100,6 @@ WORKAROUND:
          (during macroexpansion of IN-PACKAGE,
          during macroexpansion of DEFFOO)
 
          (during macroexpansion of IN-PACKAGE,
          during macroexpansion of DEFFOO)
 

-15:
-  (SUBTYPEP '(FUNCTION (T BOOLEAN) NIL)
-            '(FUNCTION (FIXNUM FIXNUM) NIL)) => T, T
-  (Also, when this is fixed, we can enable the code in PROCLAIM which 
-  checks for incompatible FTYPE redeclarations.)
-

 19:
   (I *think* this is a bug. It certainly seems like strange behavior. But
   the ANSI spec is scary, dark, and deep.. -- WHN)
 19:
   (I *think* this is a bug. It certainly seems like strange behavior. But
   the ANSI spec is scary, dark, and deep.. -- WHN)

@@ -193,12 +170,6 @@ WORKAROUND:
 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:

-       b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT on the x86 is 
-          bogus, and should probably be 1.4012985e-45. In SBCL,
-          (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller
-          than LEAST-POSITIVE-SHORT-FLOAT. Similar problems 
-          exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT,
-          and LEAST-NEGATIVE-LONG-FLOAT.

        c: Many expressions generate floating infinity on x86/Linux:
                (/ 1 0.0)
                (/ 1 0.0d0)
        c: Many expressions generate floating infinity on x86/Linux:
                (/ 1 0.0)
                (/ 1 0.0d0)

@@ -217,14 +188,13 @@ WORKAROUND:
 
 46:
   type safety errors reported by Peter Van Eynde July 25, 2000:
 
 46:
   type safety errors reported by Peter Van Eynde July 25, 2000:

-       c: (COERCE 'AND 'FUNCTION) returns something related to
-          (MACRO-FUNCTION 'AND), but ANSI says it should raise an error.

        k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is 
           not a binary input stream, but instead cheerfully reads from
           character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
 
 60:
   The debugger LIST-LOCATIONS command doesn't work properly.
        k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is 
           not a binary input stream, but instead cheerfully reads from
           character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
 
 60:
   The debugger LIST-LOCATIONS command doesn't work properly.

+  (How should it work properly?)

 
 61:
   Compiling and loading
 
 61:
   Compiling and loading

@@ -247,12 +217,6 @@ WORKAROUND:
   crashes SBCL. In general tracing anything which is used in the 
   implementation of TRACE is likely to have the same problem.
 
   crashes SBCL. In general tracing anything which is used in the 
   implementation of TRACE is likely to have the same problem.
 

-75:
-  As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000,
-  ANSI says that WITH-OUTPUT-TO-STRING should have a keyword
-  :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for
-  WITH-OUTPUT-TO-STRING.
-

 78:
   ANSI says in one place that type declarations can be abbreviated even
   when the type name is not a symbol, e.g.
 78:
   ANSI says in one place that type declarations can be abbreviated even
   when the type name is not a symbol, e.g.

@@ -300,34 +264,6 @@ WORKAROUND:
   holding... * is not equivalent to T in many cases, such as 
     (VECTOR *) /= (VECTOR T).
 
   holding... * is not equivalent to T in many cases, such as 
     (VECTOR *) /= (VECTOR T).
 

-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
 95:
   The facility for dumping a running Lisp image to disk gets confused
   when run without the PURIFY option, and creates an unnecessarily large

@@ -554,6 +490,7 @@ WORKAROUND:
   it took more than two minutes (but less than five) for me.
 
 145:
   it took more than two minutes (but less than five) for me.
 
 145:

+  a.

   ANSI allows types `(COMPLEX ,FOO) to use very hairy values for
   FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL
   COMPLEX implementation didn't deal with this, and hasn't been
   ANSI allows types `(COMPLEX ,FOO) to use very hairy values for
   FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL
   COMPLEX implementation didn't deal with this, and hasn't been

@@ -561,6 +498,18 @@ WORKAROUND:
   conformance problem, since seems hard to construct useful code
   where it matters.)
 
   conformance problem, since seems hard to construct useful code
   where it matters.)
 

+  b.
+  * (defun foo (x)
+      (declare (type (double-float -0d0) x))
+      (declare (optimize speed))
+      (+ x (sqrt (log (random 1d0)))))
+  debugger invoked on condition of type SIMPLE-ERROR:
+    bad thing to be a type specifier: ((COMPLEX
+                                        (DOUBLE-FLOAT 0.0d0
+                                                      #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY))
+                                       #C(0.0d0 #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY)
+                                       #C(0.0d0 #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY))
+

 146:
   Floating point errors are reported poorly. E.g. on x86 OpenBSD
   with sbcl-0.7.1, 
 146:
   Floating point errors are reported poorly. E.g. on x86 OpenBSD
   with sbcl-0.7.1, 

@@ -573,41 +522,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

@@ -703,6 +617,15 @@ WORKAROUND:
                (print (incf start 22))
                (print (incf start 26))))))
 
                (print (incf start 22))
                (print (incf start 26))))))
 

+  This example could be solved with clever enough constraint
+  propagation or with SSA, but consider
+
+    (let ((x 0))
+      (loop (incf x 2)))
+
+  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"
   In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs
   on the PPC/Linux platform, waiting for a zombie env process.  This
 190: "PPC/Linux pipe? buffer? bug"
   In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs
   on the PPC/Linux platform, waiting for a zombie env process.  This

@@ -731,7 +654,6 @@ WORKAROUND:
   c. the examples in CLHS 7.6.5.1 (regarding generic function lambda
      lists and &KEY arguments) do not signal errors when they should.
 
   c. the examples in CLHS 7.6.5.1 (regarding generic function lambda
      lists and &KEY arguments) do not signal errors when they should.
 

-

 201: "Incautious type inference from compound types"
   a. (reported by APD sbcl-devel 2002-09-17)
     (DEFUN FOO (X)
 201: "Incautious type inference from compound types"
   a. (reported by APD sbcl-devel 2002-09-17)
     (DEFUN FOO (X)

@@ -897,22 +819,7 @@ WORKAROUND:
    Then (FOO #\1 *STANDARD-OUTPUT*) signals type error.
 
   (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not
    Then (FOO #\1 *STANDARD-OUTPUT*) signals type error.
 
   (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not

-  produce invalid code, but type checking is not accurate. Similar
-  problems exist with VALUES-TYPE-INTERSECTION.)
-
-220:
-  Sbcl 0.7.9 fails to compile
-
-  (multiple-value-call #'list
-    (the integer (helper))
-    nil)
-
-  Type check for INTEGER, the result of which serves as the first
-  argument of M-V-C, is inserted after evaluation of NIL. So arguments
-  of M-V-C are pushed in the wrong order. As a temporary workaround
-  type checking was disabled for M-V-Cs in 0.7.9.13. A better solution
-  would be to put the check between evaluation of arguments, but it
-  could be tricky to check result types of PROG1, IF etc.
+  produce invalid code, but type checking is not accurate.)

 
 233: bugs in constraint propagation
   a.
 
 233: bugs in constraint propagation
   a.

@@ -1057,6 +964,149 @@ WORKAROUND:
 257:
   Complex array type does not have corresponding type specifier.
 
 257:
   Complex array type does not have corresponding type specifier.
 

+  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
+  intentionally so that it should shut up and just compile the code.
+
+  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.
+
+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().
+
+266:
+  David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix
+  behaviour of streams with element-type (SIGNED-BYTE 8).  The patch
+  looks reasonable, if not obviously correct; however, it caused the
+  PPC/Linux port to segfault during warm-init while loading
+  src/pcl/std-class.fasl.  A workaround patch was made, but it would
+  be nice to understand why the first patch caused problems, and to
+  fix the cause if possible.
+
+268: "wrong free declaration scope"
+  The following code must signal type error:
+
+    (locally (declare (optimize (safety 3)))
+      (flet ((foo (x &optional (y (car x)))
+               (declare (optimize (safety 0)))
+               (list x y)))
+        (funcall (eval #'foo) 1)))
+
+269:
+  SCALE-FLOAT should accept any integer for its second argument.
+
+270:
+  In the following function constraint propagator optimizes nothing:
+
+    (defun foo (x)
+      (declare (integer x))
+      (declare (optimize speed))
+      (typecase x
+        (fixnum "hala")
+        (fixnum "buba")
+        (bignum "hip")
+        (t "zuz")))
+
+272:
+  All forms of GC hooks (including notifiers and finalisers) are currently
+  (since 0.8.0) broken for gencgc (i.e. x86) users 
+
+273:
+  Compilation of the following two forms causes "X is unbound" error:
+
+    (symbol-macrolet ((x pi))
+      (macrolet ((foo (y) (+ x y)))
+        (declaim (inline bar))
+        (defun bar (z)
+          (* z (foo 4)))))
+    (defun quux (z)
+      (bar z))
+
+  (See (COERCE (CDR X) 'FUNCTION) in IR1-CONVERT-INLINE-LAMBDA.)
+
+274:
+  CLHS says that type declaration of a symbol macro should not affect
+  its expansion, but in SBCL it does.
+
+275:
+  The following code (taken from CLOCC) takes a lot of time to compile:
+
+    (defun foo (n)
+      (declare (type (integer 0 #.large-constant) n))
+      (expt 1/10 n))
+
+  (fixed in 0.8.2.51, but a test case would be good)
+
+276:
+    (defmethod fee ((x fixnum))
+      (setq x (/ x 2))
+      x)
+    (fee 1) => type error
+
+  (taken from CLOCC)
+
+277:
+  IGNORE/IGNORABLE declarations should be acceptable for symbol
+  macros.
+
+

 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
     These labels were used for bugs related to the old IR1 interpreter.
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
     These labels were used for bugs related to the old IR1 interpreter.