0.pre8.113:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index 5341a1f..5a4d7c5 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -101,20 +101,6 @@ WORKAROUND:
     (frob-stringwise-foo *stringwise-foo*)
   SEGV.
 
     (frob-stringwise-foo *stringwise-foo*)
   SEGV.
 
-6:
-  bogus warnings about undefined functions for magic functions like
-  SB!C::%%DEFUN and SB!C::%DEFCONSTANT when cross-compiling files
-  like src/code/float.lisp. Fixing this will probably require
-  straightening out enough bootstrap consistency issues that
-  the cross-compiler can run with *TYPE-SYSTEM-INITIALIZED*.
-  Instead, the cross-compiler runs in a slightly flaky state
-  which is sane enough to compile SBCL itself, but which is
-  also unstable in several ways, including its inability
-  to really grok function declarations.
-
-  As of sbcl-0.7.5, sbcl's cross-compiler does run with
-  *TYPE-SYSTEM-INITIALIZED*; however, this bug remains.
-
 7:
   The "compiling top-level form:" output ought to be condensed.
   Perhaps any number of such consecutive lines ought to turn into a
 7:
   The "compiling top-level form:" output ought to be condensed.
   Perhaps any number of such consecutive lines ought to turn into a
@@ -158,16 +144,6 @@ WORKAROUND:
     (FORMAT NIL  "~,1G" 1.4) => "1.    "
     (FORMAT NIL "~3,1G" 1.4) => "1.    "
 
     (FORMAT NIL  "~,1G" 1.4) => "1.    "
     (FORMAT NIL "~3,1G" 1.4) => "1.    "
 
-20:
-  from Marco Antoniotti on cmucl-imp mailing list 1 Mar 2000:
-       (defclass ccc () ())
-       (setf (find-class 'ccc1) (find-class 'ccc))
-       (defmethod zut ((c ccc1)) 123)
-  In sbcl-0.7.1.13, this gives an error, 
-       There is no class named CCC1.
-  DTC's recommended workaround from the mailing list 3 Mar 2000:
-       (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc))
-
 27:
   Sometimes (SB-EXT:QUIT) fails with 
        Argh! maximum interrupt nesting depth (4096) exceeded, exiting
 27:
   Sometimes (SB-EXT:QUIT) fails with 
        Argh! maximum interrupt nesting depth (4096) exceeded, exiting
@@ -252,8 +228,8 @@ 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 is bogus, and 
-          should probably be 1.4012985e-45. In SBCL,
+       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,
           (/ 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,
@@ -300,12 +276,6 @@ WORKAROUND:
              (ADD-METHOD (FUNCTION FOO03) M)))
           should give an error, but SBCL allows it.
 
              (ADD-METHOD (FUNCTION FOO03) M)))
           should give an error, but SBCL allows it.
 
-52:
-  It has been reported (e.g. by Peter Van Eynde) that there are 
-  several metaobject protocol "errors". (In order to fix them, we might
-  need to document exactly what metaobject protocol specification
-  we're following -- the current code is just inherited from PCL.)
-
 60:
   The debugger LIST-LOCATIONS command doesn't work properly.
 
 60:
   The debugger LIST-LOCATIONS command doesn't work properly.
 
@@ -370,18 +340,6 @@ WORKAROUND:
   (partially alleviated in sbcl-0.7.9.32 by a fix by Matthew Danish to
    make the temporary filename less easily guessable)
 
   (partially alleviated in sbcl-0.7.9.32 by a fix by Matthew Danish to
    make the temporary filename less easily guessable)
 
-82: 
-  Functions are assigned names based on the context in which they're
-  defined. This is less than ideal for the functions which are
-  used to implement CLOS methods. E.g. the output of 
-  (DESCRIBE 'PRINT-OBJECT) lists functions like 
-       #<FUNCTION "DEF!STRUCT (TRACE-INFO (:MAKE-LOAD-FORM-FUN SB-KERNEL:JUST-DUMP-IT-NORMALLY) (:PRINT-OBJECT #))" {1020E49}> 
-  and
-       #<FUNCTION "MACROLET ((FORCE-DELAYED-DEF!METHODS NIL #))" {1242871}>
-  It would be better if these functions' names always identified
-  them as methods, and identified their generic functions and
-  specializers.
-
 83:
   RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
   RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
 83:
   RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
   RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
@@ -716,6 +674,9 @@ WORKAROUND:
   expansion, leaving garbage consisting of infinished blocks of the
   partially converted function.)
 
   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
@@ -884,6 +845,28 @@ WORKAROUND:
            (INTEGER 1296 1296)
            ...)>)[:EXTERNAL]
 
            (INTEGER 1296 1296)
            ...)>)[:EXTERNAL]
 
+  In recent SBCL the following example also illustrates this bug:
+
+    (time (compile
+           nil
+           '(lambda ()
+             (declare (optimize (safety 3)))
+             (declare (optimize (compilation-speed 2)))
+             (declare (optimize (speed 1) (debug 1) (space 1)))
+             (let ((start 4))
+               (declare (type (integer 0) start))
+               (print (incf start 22))
+               (print (incf start 26))
+               (print (incf start 28)))
+             (let ((start 6))
+               (declare (type (integer 0) start))
+               (print (incf start 22))
+               (print (incf start 26)))
+             (let ((start 10))
+               (declare (type (integer 0) start))
+               (print (incf start 22))
+               (print (incf start 26))))))
+
 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
@@ -1169,17 +1152,6 @@ WORKAROUND:
 229:
   (subtypep 'function '(function)) => nil, t.
 
 229:
   (subtypep 'function '(function)) => nil, t.
 
-231: "SETQ does not correctly check the type of a variable being set"
-  b.
-    (defun foo (x z)
-      (declare (type integer x))
-      (locally (declare (type (real 1) x))
-        (setq x z))
-      (list x z))
-    (foo 0 0) => (0 0).
-
-  (fixed in 0.7.12.8)
-
 233: bugs in constraint propagation
   a.
   (defun foo (x)
 233: bugs in constraint propagation
   a.
   (defun foo (x)
@@ -1203,9 +1175,6 @@ WORKAROUND:
         (+ x 2)))
   (foo 1d0 5) => segmentation violation
 
         (+ x 2)))
   (foo 1d0 5) => segmentation violation
 
-234:
-  (fixed in sbcl-0.7.10.36)
-
 235: "type system and inline expansion"
   a.
   (declaim (ftype (function (cons) number) acc))
 235: "type system and inline expansion"
   a.
   (declaim (ftype (function (cons) number) acc))
@@ -1273,6 +1242,76 @@ WORKAROUND:
   compiler gets its hands on the code needing compilation from the REPL,
   it has been macroexpanded several times.
 
   compiler gets its hands on the code needing compilation from the REPL,
   it has been macroexpanded several times.
 
+  A symptom of the same underlying problem, reported by Tony Martinez:
+    * (handler-case
+        (with-input-from-string (*query-io* "    no")
+          (yes-or-no-p))
+      (simple-type-error () 'error))
+    ; in: LAMBDA NIL
+    ;     (SB-KERNEL:FLOAT-WAIT)
+    ; 
+    ; note: deleting unreachable code
+    ; compilation unit finished
+    ;   printed 1 note
+
+241: "DEFCLASS mysteriously remembers uninterned accessor names."
+  (from tonyms on #lisp IRC 2003-02-25)
+  In sbcl-0.7.12.55, typing
+    (defclass foo () ((bar :accessor foo-bar)))
+    (profile foo-bar)
+    (unintern 'foo-bar)
+    (defclass foo () ((bar :accessor foo-bar)))
+  gives the error message
+    "#:FOO-BAR already names an ordinary function or a macro."
+  So it's somehow checking the uninterned old accessor name instead
+  of the new requested accessor name, which seems broken to me (WHN).
+
+242: "WRITE-SEQUENCE suboptimality"
+  (observed from clx performance)
+  In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type 
+  (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) on a stream with element-type
+  (UNSIGNED-BYTE 8) will write to the stream one byte at a time,
+  rather than writing the sequence in one go, leading to severe
+  performance degradation.
+
+243: "STYLE-WARNING overenthusiasm for unused variables"
+  (observed from clx compilation)
+  In sbcl-0.7.14, in the presence of the macros
+    (DEFMACRO FOO (X) `(BAR ,X))
+    (DEFMACRO BAR (X) (DECLARE (IGNORABLE X)) 'NIL)
+  somewhat surprising style warnings are emitted for
+    (COMPILE NIL '(LAMBDA (Y) (FOO Y))):
+  ; in: LAMBDA (Y)
+  ;     (LAMBDA (Y) (FOO Y))
+  ; 
+  ; 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.
+
+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".
+
 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.