1.0.22.13: fixed bug 426: nested inline expansion failure

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 7f62d6c..f58784a 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:

@@ -627,6 +629,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"

@@ -1046,7 +1050,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.
 

@@ -1511,6 +1515,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

@@ -1773,13 +1779,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)

@@ -1805,74 +1804,26 @@ WORKAROUND:
 
 419: stack-allocated indirect closure variables are not popped
 
 
 419: stack-allocated indirect closure variables are not popped
 

-    (locally (declare (optimize sb-c::stack-allocate-dynamic-extent
-                                sb-c::stack-allocate-value-cells))

       (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))))))
+              ((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
 
   (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-C::STACK-ALLOCATE-VALUE-CELLS needs to be explicitly turned on for
-  that 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.
-
-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?
+  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:
 

@@ -1906,60 +1857,43 @@ 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.
-
-427: ANY-REG not good for primitive type T
-
- ...which is true, of course, but the following should not complain
- about it (on x86 and x86-64):
-
-  (sb-alien:with-alien ((buf (array (sb-alien:signed 8) 16))))
-
- reported by Stelian Ionescu on sbcl-devel.
+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)))))
+
+430: nested structure constructors do not stack allocate
+
+  (defun nada (x) (declare (ignore x)) nil)
+
+  (declaim (inline make-foo))
+  (defstruct foo bar)
+
+  (defun foo ()
+    (let ((x (list (make-foo))))
+      (declare (dynamic-extent x))
+      (nada x)))
+
+ Result of MAKE-FOO not stack allocated in FOO, because the function
+ HANDLE-NESTED-DYNAMIC-EXTENT-LVARS sees is not
+ %MAKE-STRUCTURE-INSTANCE, but no-yet-eliminated (VARARGS-ENTRY
+ MAKE-FOO).

 
 

+431: alien strucure redefinition doesn't work as expected
+  fixed in 1.0.21.29