1.0.23.58: bug 405 has been fixed a while now

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 75a62e0..414d010 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -416,6 +416,8 @@ WORKAROUND:
   isn't too surprising since there are many differences in stack
   implementation and GC conservatism between the X86 and other ports.)
 
   isn't too surprising since there are many differences in stack
   implementation and GC conservatism between the X86 and other ports.)
 

+  (Can't reproduce on x86 linux as of 1.0.20.23 - MGL)
+

   This is probably the same bug as 216
 
 173:
   This is probably the same bug as 216
 
 173:

@@ -556,11 +558,6 @@ WORKAROUND:
   c. The cross-compiler cannot inline functions defined in a non-null
      lexical environment.
 
   c. The cross-compiler cannot inline functions defined in a non-null
      lexical environment.
 

-206: ":SB-FLUID feature broken"
-  (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07)
-  Enabling :SB-FLUID in the target-features list in sbcl-0.7.8 breaks
-  the build.
-

 207: "poorly distributed SXHASH results for compound data"
   SBCL's SXHASH could probably try a little harder. ANSI: "the
   intent is that an implementation should make a good-faith
 207: "poorly distributed SXHASH results for compound data"
   SBCL's SXHASH could probably try a little harder. ANSI: "the
   intent is that an implementation should make a good-faith

@@ -609,21 +606,14 @@ WORKAROUND:
      can erroneously return T.
 
 215: ":TEST-NOT handling by functions"
      can erroneously return T.
 
 215: ":TEST-NOT handling by functions"

-  a. FIND and POSITION currently signal errors when given non-NIL for
-     both their :TEST and (deprecated) :TEST-NOT arguments, but by
-     ANSI 17.2 "the consequences are unspecified", which by ANSI 1.4.2
-     means that the effect is "unpredictable but harmless".  It's not
-     clear what that actually means; it may preclude conforming
-     implementations from signalling errors.
-  b. COUNT, REMOVE and the like give priority to a :TEST-NOT argument
-     when conflict occurs.  As a quality of implementation issue, it
-     might be preferable to treat :TEST and :TEST-NOT as being in some
-     sense the same &KEY, and effectively take the first test function in
-     the argument list.
-  c. Again, a quality of implementation issue: it would be good to issue a
-     STYLE-WARNING at compile-time for calls with :TEST-NOT, and a
-     WARNING for calls with both :TEST and :TEST-NOT; possibly this
-     latter should be WARNed about at execute-time too.
+  
+  We should verify that our handling of :TEST-NOT and :TEST is consistent
+  for all functions that accept them: that is, signal an error if both
+  are specified.
+
+  Similarly, a compile-time full warning for calls with both would be good.
+
+  We might also consider a compile-time style warning for :TEST-NOT.

 
 216: "debugger confused by frames with invalid number of arguments"
   In sbcl-0.7.8.51, executing e.g. (VECTOR-PUSH-EXTEND T), BACKTRACE, Q
 
 216: "debugger confused by frames with invalid number of arguments"
   In sbcl-0.7.8.51, executing e.g. (VECTOR-PUSH-EXTEND T), BACKTRACE, Q

@@ -632,6 +622,8 @@ WORKAROUND:
   the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may
   not be the actual problem. (CMU CL 18c doesn't have problems with this.)
 
   the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may
   not be the actual problem. (CMU CL 18c doesn't have problems with this.)
 

+  (Can't reproduce on x86 linux as of 1.0.20.22 - MGL)
+

   This is probably the same bug as 162
 
 235: "type system and inline expansion"
   This is probably the same bug as 162
 
 235: "type system and inline expansion"

@@ -842,14 +834,6 @@ WORKAROUND:
 
   (fixed in 0.8.2.51, but a test case would be good)
 
 
   (fixed in 0.8.2.51, but a test case would be good)
 

-276:
-  b. The same as in a., but using MULTIPLE-VALUE-SETQ instead of SETQ.
-  c. (defvar *faa*)
-     (defmethod faa ((*faa* double-float))
-           (set '*faa* (when (< *faa* 0) (- *faa*)))
-           (1+ *faa*))
-     (faa 1d0) => type error
-

 279: type propagation error -- correctly inferred type goes astray?
   In sbcl-0.8.3 and sbcl-0.8.1.47, the warning
        The binding of ABS-FOO is a (VALUES (INTEGER 0 0)
 279: type propagation error -- correctly inferred type goes astray?
   In sbcl-0.8.3 and sbcl-0.8.1.47, the warning
        The binding of ABS-FOO is a (VALUES (INTEGER 0 0)

@@ -1051,7 +1035,7 @@ WORKAROUND:
     (open "/dev/zero" :element-type '(unsigned-byte 1025))
   gives an error in sbcl-0.8.10.
 
     (open "/dev/zero" :element-type '(unsigned-byte 1025))
   gives an error in sbcl-0.8.10.
 

-325: "CLOSE :ABORT T on supeseding streams"
+325: "CLOSE :ABORT T on superseding streams"

   Closing a stream opened with :IF-EXISTS :SUPERSEDE with :ABORT T leaves no
   file on disk, even if one existed before opening.
 
   Closing a stream opened with :IF-EXISTS :SUPERSEDE with :ABORT T leaves no
   file on disk, even if one existed before opening.
 

@@ -1134,25 +1118,6 @@ WORKAROUND:
      in the wrapper, and then to update the instance just run through
      all the old wrappers in order from oldest to newest.
 
      in the wrapper, and then to update the instance just run through
      all the old wrappers in order from oldest to newest.
 

-332: "fasl stack inconsistency in structure redefinition"
-  (reported by Tim Daly Jr sbcl-devel 2004-05-06)
-  Even though structure redefinition is undefined by the standard, the
-  following behaviour is suboptimal: running
-    (defun stimulate-sbcl ()
-      (let ((filename (format nil "/tmp/~A.lisp" (gensym))))
-        ;;create a file which redefines a structure incompatibly
-        (with-open-file (f filename :direction :output :if-exists :supersede)
-          (print '(defstruct astruct foo) f)
-          (print '(defstruct astruct foo bar) f))
-        ;;compile and load the file, then invoke the continue restart on
-        ;;the structure redefinition error
-        (handler-bind ((error (lambda (c) (continue c))))
-          (load (compile-file filename)))))
-    (stimulate-sbcl)
-  and choosing the CONTINUE restart yields the message
-    debugger invoked on a SB-INT:BUG in thread 27726:
-      fasl stack not empty when it should be
-

 336: "slot-definitions must retain the generic functions of accessors"
   reported by Tony Martinez:
     (defclass foo () ((bar :reader foo-bar)))
 336: "slot-definitions must retain the generic functions of accessors"
   reported by Tony Martinez:
     (defclass foo () ((bar :reader foo-bar)))

@@ -1397,30 +1362,6 @@ WORKAROUND:
   Expected: ERROR
   Got: #<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION FOO>
 
   Expected: ERROR
   Got: #<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION FOO>
 

-369: unlike-an-intersection behavior of VALUES-TYPE-INTERSECTION
-  In sbcl-0.8.18.2, the identity $(x \cap y \cap y)=(x \cap y)$ 
-  does not hold for VALUES-TYPE-INTERSECTION, even for types which
-  can be intersected exactly, so that ASSERTs fail in this test case:
-    (in-package :cl-user)
-    (let ((types (mapcar #'sb-c::values-specifier-type 
-                         '((values (vector package) &optional)
-                           (values (vector package) &rest t)
-                           (values (vector hash-table) &rest t)
-                           (values (vector hash-table) &optional)
-                           (values t &optional)
-                           (values t &rest t)
-                           (values nil &optional)
-                           (values nil &rest t)
-                           (values sequence &optional)
-                           (values sequence &rest t)
-                           (values list &optional)
-                           (values list &rest t)))))
-       (dolist (x types)
-         (dolist (y types)
-           (let ((i (sb-c::values-type-intersection x y)))
-             (assert (sb-c::type= i (sb-c::values-type-intersection i x)))
-             (assert (sb-c::type= i (sb-c::values-type-intersection i y)))))))
-

 370: reader misbehaviour on large-exponent floats
     (read-from-string "1.0s1000000000000000000000000000000000000000")
   causes the reader to attempt to create a very large bignum (which it
 370: reader misbehaviour on large-exponent floats
     (read-from-string "1.0s1000000000000000000000000000000000000000")
   causes the reader to attempt to create a very large bignum (which it

@@ -1458,19 +1399,6 @@ WORKAROUND:
 379: TRACE :ENCAPSULATE NIL broken on ppc/darwin
   See commented-out test-case in debug.impure.lisp.
 
 379: TRACE :ENCAPSULATE NIL broken on ppc/darwin
   See commented-out test-case in debug.impure.lisp.
 

-380: Accessor redefinition fails because of old accessor name
-  When redefining an accessor, SB-PCL::FIX-SLOT-ACCESSORS may try to
-  find the generic function named by the old accessor name using
-  ENSURE-GENERIC-FUNCTION and then remove the old accessor's method in
-  the GF. If the old name does not name a function, or if the old name
-  does not name a generic function, no attempt to find the GF or remove
-  any methods is made.
-
-  However, if an unrelated GF with an incompatible lambda list exists,
-  the class redefinition will fail when SB-PCL::REMOVE-READER-METHOD
-  tries to find and remove a method with an incompatible lambda list
-  from the unrelated generic function.
-

 382: externalization unexpectedly changes array simplicity
   COMPILE-FILE and LOAD
     (defun foo ()
 382: externalization unexpectedly changes array simplicity
   COMPILE-FILE and LOAD
     (defun foo ()

@@ -1516,6 +1444,8 @@ WORKAROUND:
 385:
   (format nil "~4,1F" 0.001) => "0.00" (should be " 0.0");
   (format nil "~4,1@F" 0.001) => "+.00" (should be "+0.0").
 385:
   (format nil "~4,1F" 0.001) => "0.00" (should be " 0.0");
   (format nil "~4,1@F" 0.001) => "+.00" (should be "+0.0").

+  (format nil "~E" 0.01) => "10.e-3" (should be "1.e-2");
+  (format nil "~G" 0.01) => "10.e-3" (should be "1.e-2");

 
 386: SunOS/x86 stack exhaustion handling broken
   According to <http://alfa.s145.xrea.com/sbcl/solaris-x86.html>, the
 
 386: SunOS/x86 stack exhaustion handling broken
   According to <http://alfa.s145.xrea.com/sbcl/solaris-x86.html>, the

@@ -1668,17 +1598,6 @@ WORKAROUND:
   perhaps because CLISP has shuffled the clauses into an 
   ANSI-compliant order before proceeding.
 
   perhaps because CLISP has shuffled the clauses into an 
   ANSI-compliant order before proceeding.
 

-405: a TYPE-ERROR in MERGE-LETS exercised at DEBUG 3
-  In sbcl-0.9.16.21 on linux/86, compiling 
-    (declaim (optimize (debug 3)))
-    (defstruct foo bar)
-    (let ()
-      (flet ((i (x) (frob x (foo-bar foo))))
-        (i :five)))
-  causes a TYPE-ERROR 
-    The value NIL is not of type SB-C::PHYSENV.
-  in MERGE-LETS.
-

 406: functional has external references -- failed aver
  Given the following food in a single file
   (eval-when (:compile-toplevel :load-toplevel :execute)
 406: functional has external references -- failed aver
  Given the following food in a single file
   (eval-when (:compile-toplevel :load-toplevel :execute)

@@ -1778,13 +1697,6 @@ WORKAROUND:
   implementation of read circularity, using a symbol as a marker for
   the previously-referenced object.
 
   implementation of read circularity, using a symbol as a marker for
   the previously-referenced object.
 

-415: Issues creating large arrays on x86-64/Linux and x86/Darwin
-
-   (make-array (1- array-dimension-limit))
-
-   causes a GC invariant violation on x86-64/Linux, and
-   an unhandled SIGILL on x86/Darwin.
-

 416: backtrace confusion
 
   (defun foo (x)
 416: backtrace confusion
 
   (defun foo (x)

@@ -1810,67 +1722,26 @@ WORKAROUND:
 
 419: stack-allocated indirect closure variables are not popped
 
 
 419: stack-allocated indirect closure variables are not popped
 

-    (locally (declare (optimize speed (safety 0)))

       (defun bug419 (x)
         (multiple-value-call #'list
           (eval '(values 1 2 3))
           (let ((x x))
       (defun bug419 (x)
         (multiple-value-call #'list
           (eval '(values 1 2 3))
           (let ((x x))

-            (declare (dynamic-extent x))
+            (declare (sb-int:truly-dynamic-extent x))

             (flet ((mget (y)
                      (+ x y))
                    (mset (z)
                      (incf x z)))
               (declare (dynamic-extent #'mget #'mset))
             (flet ((mget (y)
                      (+ x y))
                    (mset (z)
                      (incf x z)))
               (declare (dynamic-extent #'mget #'mset))

-              ((lambda (f g) (eval `(progn ,f ,g (values 4 5 6)))) #'mget #'mset))))))
-
-  (ASSERT (EQUAL (BUG419) '(1 2 3 4 5 6))) => failure
-
-420: The MISC.556 test from gcl/ansi-tests/misc.lsp fails hard.
-
-In sbcl-1.0.13 on Linux/x86, executing 
-       (FUNCALL
-        (COMPILE NIL
-                 '(LAMBDA (P1 P2)
-                    (DECLARE
-                     (OPTIMIZE (SPEED 1) (SAFETY 0) (DEBUG 0) (SPACE 0))
-                     (TYPE (MEMBER 8174.8604) P1) (TYPE (MEMBER -95195347) P2))
-                    (FLOOR P1 P2)))
-        8174.8604 -95195347)
-interactively causes
-  SB-SYS:MEMORY-FAULT-ERROR: Unhandled memory fault at #x8.
-The gcl/ansi-tests/doit.lisp program terminates prematurely shortly after
-MISC.556 by falling into gdb with
-  fatal error encountered in SBCL pid 2827: Unhandled SIGILL
-unless the MISC.556 test is commented out.
-
-Analysis: + and a number of other arithmetic functions exhibit the
-same behaviour. Here's the underlying problem: On x86 we perform
-single-float + integer normally using double-precision, and then
-coerce the result back to single-float. (The FILD instruction always
-gives us a double-float, and unless we do MOVE-FROM-SINGLE it remains
-one. Or so it seems to me, and that would also explain the observed
-behaviour below.)
-
-During IR1 we derive the types for both
-
- (+ <single> <integer>)                   ; uses double-precision
- (+ <single> (FLOAT <integer> <single>))  ; uses single-precision
-
-and get a mismatch for a number of unlucky arguments. This leads to
-derived result type NIL, and ends up flushing the whole whole
-operation -- and finally we generate code without a return sequence,
-and fall through to whatever.
-
-The use of double-precision in the first case appears to be an
-(un)happy accident -- interval arithmetic gives us the
-double-precision result because that's what the backend does.
-
- (+ 8172.0 (coerce -95195347 'single-float)) ; => -9.518717e7
- (+ 8172.0 -95195347)                        ; => -9.5187176e7
- (coerce (+ 8172.0 (coerce -95195347 'double-float)) 'single-float)
-                                             ; => -9.5187176e7
-
-Which should be fixed, the IR1, or the backend?
+              ((lambda (f g) (eval `(progn ,f ,g (values 4 5 6)))) #'mget #'mset)))))
+
+  (ASSERT (EQUAL (BUG419 42) '(1 2 3 4 5 6))) => failure
+
+  Note: as of SBCL 1.0.16.29 this bug no longer affects user code, as
+  SB-INT:TRULY-DYNAMIC-EXTENT needs to be used instead of
+  DYNAMIC-EXTENT for this to happen. Proper fix for this bug requires
+  (Nikodemus thinks) storing the relevant LAMBDA-VARs in a
+  :DYNAMIC-EXTENT cleanup, and teaching stack analysis how to deal
+  with them.

 
 421: READ-CHAR-NO-HANG misbehaviour on Windows Console:
 
 
 421: READ-CHAR-NO-HANG misbehaviour on Windows Console:
 

@@ -1904,50 +1775,26 @@ generally try to check returns in safe code, so we should here too.)
 
  (Test-case adapted from CL-PPCRE.)
 
 
  (Test-case adapted from CL-PPCRE.)
 

-425: reading from closed streams
-
- Reported by Damien Cassou on sbcl-devel. REPL transcript follows:
-
-  * (open ".bashrc" :direction :input)
-  #<SB-SYS:FD-STREAM for "file /home/cassou/.bashrc" {A6ADFC9}>
-  * (defparameter *s* *)
-  *S*
-  * (read-line *s*)
-  "# -*- Mode: Sh -*-"
-  * (read-line *s*)
-  "# Files you make look like rw-r--r--"
-  * (open-stream-p *s*)
-  T
-  * (close *s*)
-  T
-  * (open-stream-p *s*)
-  NIL
-  * (read-line *s*)
-  "umask 022"
-
- The problem is with the fast path using ansi-stream-cin-buffer not hitting
- closed-flame.
-
-426: inlining failure involving multiple nested calls
-
-   (declaim (inline foo))
-   (defun foo (x y)
-     (cons x y))
-   (defun bar (x)
-     (foo (foo x x) (foo x x)))
-   ;; shows a full call to FOO
-   (disassemble 'bar)
-   ;; simple way to test this programmatically
-   (let ((code (sb-c::fun-code-header #'bar))
-         (foo (sb-impl::fdefinition-object 'foo nil)))
-     (loop for i from sb-vm:code-constants-offset below (sb-kernel:get-header-data code)
-           do (assert (not (eq foo (sb-kernel:code-header-ref code i))))))
-
- This appears to be an ancient bug, inherited from CMUCL: reportedly
- 18c does the same thing. RECOGNIZE-KNOWN-CALL correctly picks up only
- one of the calls, but local call analysis fails to inline the call
- for the second time. Nikodemus thinks (but is not 100% sure based on
- very brief investigation) that the call that is not inlined is the
- second nested one. A trivial fix is to call CHANGE-REF-LEAF in known
- call for functions already inline converted there, but he is not sure
- if this has adverse effects elsewhere.
+428: TIMER SCHEDULE-STRESS and PARALLEL-UNSCHEDULE in
+     timer.impure.lisp fails
+
+ Failure modes vary. Core problem seems to be (?) recursive entry to
+ RUN-EXPIRED-TIMERS.
+
+429: compiler hangs
+
+  Compiling a file with this contents makes the compiler loop in
+  ORDER-UVL-SETS:
+
+  (declaim (inline storage))
+  (defun storage (x)
+    (the (simple-array flt (*)) (unknown x)))
+
+  (defun test1 (lumps &key cg)
+    (let ((nodes (map 'list (lambda (lump) (storage lump))
+                      lumps)))
+      (setf (aref nodes 0) 2)
+      (assert (every #'~= (apply #'concatenate 'list nodes) '(2 3 6 9)))))
+
+431: alien strucure redefinition doesn't work as expected
+  fixed in 1.0.21.29