X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=8fd2a83a643565274d856f02eb6ac077d8e727bd;hb=6b8baeece6cf870e3f979a9f09c32985c64c04de;hp=75a62e01869c832cb0bbdb6cff67c3bf5206c88d;hpb=3a4d9dd3adbe53a69867e3f3a1d9d04833b27bb3;p=sbcl.git

diff --git a/BUGS b/BUGS
index 75a62e0..8fd2a83 100644
--- a/BUGS
+++ b/BUGS
@@ -556,11 +556,6 @@ WORKAROUND:
   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
@@ -1810,67 +1805,26 @@ WORKAROUND:
 
 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))
-            (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))
-              ((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.26.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:
 
@@ -1904,30 +1858,6 @@ generally try to check returns in safe code, so we should here too.)
 
  (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))
@@ -1951,3 +1881,8 @@ generally try to check returns in safe code, so we should here too.)
  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 in timer.impure.lisp fails
+
+ Failure modes vary. Core problem seems to be (?) recursive entry to
+ RUN-EXPIRED-TIMERS.