0.8.0.78.vector-nil-string.10:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 910d617..185c178 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -108,23 +108,6 @@ WORKAROUND:
   Perhaps any number of such consecutive lines ought to turn into a
   single "compiling top-level forms:" line.
 
   Perhaps any number of such consecutive lines ought to turn into a
   single "compiling top-level forms:" line.
 

-10:
-  The way that the compiler munges types with arguments together
-  with types with no arguments (in e.g. TYPE-EXPAND) leads to
-  weirdness visible to the user:
-       (DEFTYPE FOO () 'FIXNUM)
-       (TYPEP 11 'FOO) => T
-       (TYPEP 11 '(FOO)) => T, which seems weird
-       (TYPEP 11 'FIXNUM) => T
-       (TYPEP 11 '(FIXNUM)) signals an error, as it should
-  The situation is complicated by the presence of Common Lisp types
-  like UNSIGNED-BYTE (which can either be used in list form or alone)
-  so I'm not 100% sure that the behavior above is actually illegal.
-  But I'm 90+% sure, and the following related behavior,
-       (TYPEP 11 'AND) => T
-  treating the bare symbol AND as equivalent to '(AND), is specifically
-  forbidden (by the ANSI specification of the AND type).
-

 11:
   It would be nice if the
        caught ERROR:
 11:
   It would be nice if the
        caught ERROR:

@@ -134,12 +117,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)

@@ -207,13 +184,6 @@ WORKAROUND:
   so they could be supported after all. Very likely 
   SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
 
   so they could be supported after all. Very likely 
   SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
 

-43:
-  (as discussed by Douglas Crosher on the cmucl-imp mailing list ca. 
-  Aug. 10, 2000): CMUCL currently interprets 'member as '(member); same
-  issue with 'union, 'and, 'or etc. So even though according to the
-  ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL
-  (and now SBCL) interpret them as legal types.
-

 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:

@@ -241,14 +211,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

@@ -368,20 +337,31 @@ WORKAROUND:
   so the compiler doesn't compile the type test into code, but
   instead just saves the type in a lexical closure and interprets it
   at runtime.
   so the compiler doesn't compile the type test into code, but
   instead just saves the type in a lexical closure and interprets it
   at runtime.

-    A proper solution involves deciding whether it's really worth
-  saving space by implementing structure slot accessors as closures.
-  (If it's not worth it, the problem vanishes automatically. If it
-  is worth it, there are hacks we could use to force type tests to
-  be compiled anyway, and even shared. E.g. we could implement
-  an EQUAL hash table mapping from types to compiled type tests, 
-  and save the appropriate compiled type test as part of each lexical
-  closure; or we could make the lexical closures be placeholders
-  which overwrite their old definition as a lexical closure with
-  a new compiled definition the first time that they're called.)
-    As a workaround for the problem, #'(SETF FOO) expressions can
-  be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
+    To exercise the problem, compile and load
+      (cl:in-package :cl-user)
+      (defstruct foo
+        (bar (error "missing") :type bar))
+      (defvar *foo*)
+      (defun wastrel1 (x)
+        (loop (setf (foo-bar *foo*) x)))
+      (defstruct bar)
+      (defvar *bar* (make-bar))
+      (defvar *foo* (make-foo :bar *bar*))
+      (defvar *setf-foo-bar* #'(setf foo-bar))
+      (defun wastrel2 (x)
+        (loop (funcall *setf-foo-bar* x *foo*)))
+  then run (WASTREL1 *BAR*) or (WASTREL2 *BAR*), hit Ctrl-C, and
+  use BACKTRACE, to see it's spending all essentially all its time
+  in %TYPEP and VALUES-SPECIFIER-TYPE and so forth.
+    One possible solution would be simply to give up on 
+  representing structure slot accessors as functions, and represent
+  them as macroexpansions instead. This can be inconvenient for users,
+  but it's not clear that it's worse than trying to help by expanding
+  into a horribly inefficient implementation.
+    As a workaround for the problem, #'(SETF FOO) expressions
+  can be replaced with (EFFICIENT-SETF-FUNCTION FOO), where

 (defmacro efficient-setf-function (place-function-name)
 (defmacro efficient-setf-function (place-function-name)

-  (or #+sbcl (and (sb-impl::info :function :accessor-for place-function-name)
+  (or #+sbcl (and (sb-int:info :function :accessor-for place-function-name)

                  ;; a workaround for the problem, encouraging the
                  ;; inline expansion of the structure accessor, so
                  ;; that the compiler can optimize its type test
                  ;; a workaround for the problem, encouraging the
                  ;; inline expansion of the structure accessor, so
                  ;; that the compiler can optimize its type test

@@ -566,22 +546,6 @@ WORKAROUND:
   under OpenBSD 2.9 on my X86 laptop. Do be patient when you try it:
   it took more than two minutes (but less than five) for me.
 
   under OpenBSD 2.9 on my X86 laptop. Do be patient when you try it:
   it took more than two minutes (but less than five) for me.
 

-144: 
-  (This was once known as IR1-4, but it lived on even after the
-  IR1 interpreter went to the big bit bucket in the sky.)
-  The system accepts DECLAIM in most places where DECLARE would be 
-  accepted, without even issuing a warning. ANSI allows this, but since
-  it's fairly easy to mistype DECLAIM instead of DECLARE, and the
-  meaning is rather different, and it's unlikely that the user
-  has a good reason for doing DECLAIM not at top level, it would be 
-  good to issue a STYLE-WARNING when this happens. A possible
-  fix would be to issue STYLE-WARNINGs for DECLAIMs not at top level,
-  or perhaps to issue STYLE-WARNINGs for any EVAL-WHEN not at top level.
-  [This is considered an IR1-interpreter-related bug because until
-  EVAL-WHEN is rewritten, which won't happen until after the IR1
-  interpreter is gone, the system's notion of what's a top-level form
-  and what's not will remain too confused to fix this problem.]
-

 145:
   ANSI allows types `(COMPLEX ,FOO) to use very hairy values for
   FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL
 145:
   ANSI allows types `(COMPLEX ,FOO) to use very hairy values for
   FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL

@@ -712,44 +676,6 @@ WORKAROUND:
           :FAST-MODE NIL)
 
 188: "compiler performance fiasco involving type inference and UNION-TYPE"
           :FAST-MODE NIL)
 
 188: "compiler performance fiasco involving type inference and UNION-TYPE"

-  (In sbcl-0.7.6.10, DEFTRANSFORM CONCATENATE was commented out until this
-  bug could be fixed properly, so you won't see the bug unless you restore
-  the DEFTRANSFORM by hand.) In sbcl-0.7.5.11 on a 700 MHz Pentium III, 
-    (time (compile
-           nil
-           '(lambda ()
-              (declare (optimize (safety 3)))
-              (declare (optimize (compilation-speed 2)))
-              (declare (optimize (speed 1) (debug 1) (space 1)))
-              (let ((fn "if-this-file-exists-the-universe-is-strange"))
-                (load fn :if-does-not-exist nil)
-                (load (concatenate 'string fn ".lisp") :if-does-not-exist nil)
-                (load (concatenate 'string fn ".fasl") :if-does-not-exist nil)
-                (load (concatenate 'string fn ".misc-garbage")
-                      :if-does-not-exist nil)))))
-  reports  
-                134.552 seconds of real time
-                133.35156 seconds of user run time
-                0.03125 seconds of system run time
-                   [Run times include 2.787 seconds GC run time.]
-                0 page faults and
-                246883368 bytes consed.
-  BACKTRACE from Ctrl-C in the compilation shows that the compiler is
-  thinking about type relationships involving types like
-     #<UNION-TYPE
-       (OR (INTEGER 576 576)
-           (INTEGER 1192 1192)
-           (INTEGER 2536 2536)
-           (INTEGER 1816 1816)
-           (INTEGER 2752 2752)
-           (INTEGER 1600 1600)
-           (INTEGER 2640 2640)
-           (INTEGER 1808 1808)
-           (INTEGER 1296 1296)
-           ...)>)[:EXTERNAL]
-
-  In recent SBCL the following example also illustrates this bug:
-

     (time (compile
            nil
            '(lambda ()
     (time (compile
            nil
            '(lambda ()

@@ -770,6 +696,17 @@ 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 (if (random-boolean)
+                (incf x 2)
+                (incf x 5))))
+
+  The careful type of X is {2k+5n} :-(. 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

@@ -798,9 +735,8 @@ 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 CONS types"
-  (reported by APD sbcl-devel 2002-09-17)
+201: "Incautious type inference from compound types"
+  a. (reported by APD sbcl-devel 2002-09-17)

     (DEFUN FOO (X)
       (LET ((Y (CAR (THE (CONS INTEGER *) X))))
         (SETF (CAR X) NIL)
     (DEFUN FOO (X)
       (LET ((Y (CAR (THE (CONS INTEGER *) X))))
         (SETF (CAR X) NIL)

@@ -813,6 +749,17 @@ WORKAROUND:
 
     (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"
 
 
     (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"
 

+  b.
+    * (defun foo (x)
+        (declare (type (array * (4 4)) x))
+        (let ((y x))
+          (setq x (make-array '(4 4)))
+          (adjust-array y '(3 5))
+          (= (array-dimension y 0) (eval `(array-dimension ,y 0)))))
+    FOO
+    * (foo (make-array '(4 4) :adjustable t))
+    NIL
+

 205: "environment issues in cross compiler"
   (These bugs have no impact on user code, but should be fixed or
   documented.)
 205: "environment issues in cross compiler"
   (These bugs have no impact on user code, but should be fixed or
   documented.)

@@ -1008,17 +955,6 @@ WORKAROUND:
 
   (foo '(nil) '(t)) => NIL, T.
 
 
   (foo '(nil) '(t)) => NIL, T.
 

-  b. (reported by brown on #lisp 2003-01-21)
-
-    (defun find-it (x)
-      (declare (optimize (speed 3) (safety 0)))
-      (declare (notinline mapcar))
-      (let ((z (mapcar #'car x)))
-        (find 'foobar z)))
-
-  Without (DECLARE (NOTINLINE MAPCAR)), Python cannot derive that Z is
-  LIST.
-

 237: "Environment arguments to type functions"
   a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and 
      UPGRADED-COMPLEX-PART-TYPE now have an optional environment
 237: "Environment arguments to type functions"
   a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and 
      UPGRADED-COMPLEX-PART-TYPE now have an optional environment

@@ -1092,14 +1028,6 @@ WORKAROUND:
   a. On X86 an immediate operand for IMUL is printed incorrectly.
   b. On X86 operand size prefix is not recognized.
 
   a. On X86 an immediate operand for IMUL is printed incorrectly.
   b. On X86 operand size prefix is not recognized.
 

-246: "NTH-VALUE scaling problem"
-  NTH-VALUE's current implementation for constant integers scales in
-  compile-time as O(n^4), as indeed must the optional dispatch
-  mechanism on which it is implemented.  While it is unlikely to
-  matter in real user code, it's still unpleasant to observe that
-  (NTH-VALUE 1000 (VALUES-LIST (MAKE-LIST 1001))) takes several hours
-  to compile.
-

 248: "reporting errors in type specifier syntax"
   (TYPEP 1 '(SYMBOL NIL)) says something about "unknown type
   specifier".
 248: "reporting errors in type specifier syntax"
   (TYPEP 1 '(SYMBOL NIL)) says something about "unknown type
   specifier".

@@ -1112,12 +1040,25 @@ WORKAROUND:
   does not cause a warning. (BTW: old SBCL issued a warning, but for a
   function, which was never called!)
 
   does not cause a warning. (BTW: old SBCL issued a warning, but for a
   function, which was never called!)
 

-253: "type checking is embedded THEs"
-  Compiler cannot perform type checking in
+256:
+  Compiler does not emit warnings for
+
+  a. (lambda () (svref (make-array 8 :adjustable t) 1))
+
+  b. (lambda (x)
+       (list (let ((y (the real x)))
+               (unless (floatp y) (error ""))
+               y)
+             (integer-length x)))

 
 

-    (let () (list (the fixnum (the unsigned-byte (eval -1)))))
+  c. (lambda (x)
+       (declare (optimize (debug 0)))
+       (declare (type vector x))
+       (list (fill-pointer x)
+             (svref x 1)))

 
 

-  (fixed in 0.8.0.34)
+257:
+  Complex array type does not have corresponding type specifier.

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