0.8.0.62:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index ab130b0..534f427 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:

@@ -199,19 +182,6 @@ WORKAROUND:
   (Also, verify that the compiler handles declared function
   return types as assertions.)
 
   (Also, verify that the compiler handles declared function
   return types as assertions.)
 

-41:
-  TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in 
-       (DEFTYPE INDEXOID () '(INTEGER 0 1000))
-       (DEFUN FOO (X)
-         (DECLARE (TYPE INDEXOID X))
-         (THE (VALUES INDEXOID)
-           (VALUES X)))
-  where the implementation of the type check in function FOO 
-  includes a full call to %TYPEP. There are also some fundamental problems
-  with the interpretation of VALUES types (inherited from CMU CL, and
-  from the ANSI CL standard) as discussed on the cmucl-imp@cons.org
-  mailing list, e.g. in Robert Maclachlan's post of 21 Jun 2000.
-

 42:
   The definitions of SIGCONTEXT-FLOAT-REGISTER and
   %SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not
 42:
   The definitions of SIGCONTEXT-FLOAT-REGISTER and
   %SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not

@@ -220,13 +190,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:

@@ -270,17 +233,6 @@ WORKAROUND:
   then requesting a BACKTRACE at the debugger prompt gives no information
   about where in the user program the problem occurred.
 
   then requesting a BACKTRACE at the debugger prompt gives no information
   about where in the user program the problem occurred.
 

-63:
-  Paul Werkowski wrote on cmucl-imp@cons.org 2000-11-15
-    I am looking into this problem that showed up on the cmucl-help
-    list. It seems to me that the "implementation specific environment
-    hacking functions" found in pcl/walker.lisp are completely messed
-    up. The good thing is that they appear to be barely used within
-    PCL and the munged environment object is passed to cmucl only
-    in calls to macroexpand-1, which is probably why this case fails.
-  SBCL uses essentially the same code, so if the environment hacking
-  is screwed up, it affects us too.
-

 64:
   Using the pretty-printer from the command prompt gives funny
   results, apparently because the pretty-printer doesn't know
 64:
   Using the pretty-printer from the command prompt gives funny
   results, apparently because the pretty-printer doesn't know

@@ -405,7 +357,7 @@ WORKAROUND:
     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)
     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)

-  (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

@@ -590,22 +542,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

@@ -735,63 +671,6 @@ WORKAROUND:
           :ACCRUED-EXCEPTIONS (:INEXACT)
           :FAST-MODE NIL)
 
           :ACCRUED-EXCEPTIONS (:INEXACT)
           :FAST-MODE NIL)
 

-187: "type inference confusion around DEFTRANSFORM time"
-  (reported even more verbosely on sbcl-devel 2002-06-28 as "strange
-  bug in DEFTRANSFORM")
-  After the file below is compiled and loaded in sbcl-0.7.5, executing
-    (TCX (MAKE-ARRAY 4 :FILL-POINTER 2) 0)
-  at the REPL returns an adjustable vector, which is wrong. Presumably
-  somehow the DERIVE-TYPE information for the output values of %WAD is
-  being mispropagated as a type constraint on the input values of %WAD,
-  and so causing the type test to be optimized away. It's unclear how
-  hand-expanding the DEFTRANSFORM would change this, but it suggests
-  the DEFTRANSFORM machinery (or at least the way DEFTRANSFORMs are
-  invoked at a particular phase) is involved.
-    (cl:in-package :sb-c)
-    (eval-when (:compile-toplevel)
-    ;;; standin for %DATA-VECTOR-AND-INDEX
-    (defknown %dvai (array index) 
-      (values t t) 
-      (foldable flushable))
-    (deftransform %dvai ((array index)
-                         (vector t)
-                         *
-                         :important t)
-      (let* ((atype (continuation-type array))
-             (eltype (array-type-specialized-element-type atype)))
-        (when (eq eltype *wild-type*)
-          (give-up-ir1-transform
-           "specialized array element type not known at compile-time"))
-        (when (not (array-type-complexp atype))
-          (give-up-ir1-transform "SIMPLE array!"))
-        `(if (array-header-p array)
-             (%wad array index nil)
-             (values array index))))
-    ;;; standin for %WITH-ARRAY-DATA
-    (defknown %wad (array index (or index null))
-      (values (simple-array * (*)) index index index)
-      (foldable flushable))
-    ;;; (Commenting out this optimizer causes the bug to go away.)
-    (defoptimizer (%wad derive-type) ((array start end))
-      (let ((atype (continuation-type array)))
-        (when (array-type-p atype)
-          (values-specifier-type
-           `(values (simple-array ,(type-specifier
-                                    (array-type-specialized-element-type atype))
-                                  (*))
-                    index index index)))))
-    ) ; EVAL-WHEN
-    (defun %wad (array start end)
-      (format t "~&in %WAD~%")
-      (%with-array-data array start end))
-    (cl:in-package :cl-user)
-    (defun tcx (v i)
-      (declare (type (vector t) v))
-      (declare (notinline sb-kernel::%with-array-data))
-      ;; (Hand-expending DEFTRANSFORM %DVAI here also causes the bug to
-      ;; go away.) 
-      (sb-c::%dvai v i))
-

 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
 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

@@ -926,15 +805,6 @@ WORKAROUND:
   to redo MIX using a lookup into a 256-entry s-box containing
   29-bit pseudorandom numbers?
 
   to redo MIX using a lookup into a 256-entry s-box containing
   29-bit pseudorandom numbers?
 

-208: "package confusion in PCL handling of structure slot handlers"
-  In sbcl-0.7.8 compiling and loading
-       (in-package :cl)
-       (defstruct foo (slot (error "missing")) :type list :read-only t)
-       (defmethod print-object ((foo foo) stream) (print nil stream))
-  causes CERROR "attempting to modify a symbol in the COMMON-LISP
-  package: FOO-SLOT". (This is fairly bad code, but still it's hard
-  to see that it should cause symbols to be interned in the CL package.)
-

 211: "keywords processing"
   a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
      number of keyword arguments.
 211: "keywords processing"
   a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
      number of keyword arguments.

@@ -1046,12 +916,6 @@ WORKAROUND:
   produce invalid code, but type checking is not accurate. Similar
   problems exist with VALUES-TYPE-INTERSECTION.)
 
   produce invalid code, but type checking is not accurate. Similar
   problems exist with VALUES-TYPE-INTERSECTION.)
 

-218: "VALUES type specifier semantics"
-  (THE (VALUES ...) ...) in safe code discards extra values.
-
-  (defun test (x y) (the (values integer) (truncate x y)))
-  (test 10 4) => 2
-

 220:
   Sbcl 0.7.9 fails to compile
 
 220:
   Sbcl 0.7.9 fails to compile
 

@@ -1066,9 +930,6 @@ WORKAROUND:
   would be to put the check between evaluation of arguments, but it
   could be tricky to check result types of PROG1, IF etc.
 
   would be to put the check between evaluation of arguments, but it
   could be tricky to check result types of PROG1, IF etc.
 

-229:
-  (subtypep 'function '(function)) => nil, t.
-

 233: bugs in constraint propagation
   a.
   (defun foo (x)
 233: bugs in constraint propagation
   a.
   (defun foo (x)

@@ -1187,34 +1048,14 @@ WORKAROUND:
   ; caught STYLE-WARNING:
   ;   The variable Y is defined but never used.
 
   ; caught STYLE-WARNING:
   ;   The variable Y is defined but never used.
 

-244: "optimizing away tests for &KEY args of type declared in DEFKNOWN"
-  (caught by clocc-ansi-test :EXCEPSIT-LEGACY-1050)
-  In sbcl-0.pre8.44, (OPEN "foo" :DIRECTION :INPUT :EXTERNAL-FORMAT 'FOO)
-  succeeds with no error (ignoring the bogus :EXTERNAL-FORMAT argument)
-  apparently because the test is optimized away. The problem doesn't 
-  exist in sbcl-0.pre8.19. Deleting the (MEMBER :DEFAULT) declaration
-  for :EXTERNAL-FORMAT in DEFKNOWN OPEN (and LOAD) is a workaround for
-  the problem (and should be removed when the problem is fixed).
-

 245: bugs in disassembler
   a. On X86 an immediate operand for IMUL is printed incorrectly.
   b. On X86 operand size prefix is not recognized.
 
 245: bugs in disassembler
   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".
 

-250:
-  (make-array nil :initial-element 11) causes a warning.
-

 251:
   (defun foo (&key (a :x))
     (declare (fixnum a))
 251:
   (defun foo (&key (a :x))
     (declare (fixnum a))

@@ -1223,6 +1064,9 @@ 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!)
 

+255:
+  (fixed in 0.8.0.57)
+

 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.