1.0.23.38: fix bug 430 (stack alloc by nested defstruct constructors)

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index ebccf55..2ca448f 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)

@@ -1819,7 +1818,7 @@ WORKAROUND:
 
   (ASSERT (EQUAL (BUG419 42) '(1 2 3 4 5 6))) => failure
 
 
   (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
+  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
   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

@@ -1858,30 +1857,6 @@ 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.)
 

-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
 
 428: TIMER SCHEDULE-STRESS and PARALLEL-UNSCHEDULE in
      timer.impure.lisp fails
 

@@ -1902,3 +1877,6 @@ generally try to check returns in safe code, so we should here too.)
                       lumps)))
       (setf (aref nodes 0) 2)
       (assert (every #'~= (apply #'concatenate 'list nodes) '(2 3 6 9)))))
                       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