1.0.22.13: fixed bug 426: nested inline expansion failure

[sbcl.git] / BUGS

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

@@ -479,6 +481,11 @@ WORKAROUND:
                (print (incf start 22))
                (print (incf start 26))))))
 
                (print (incf start 22))
                (print (incf start 26))))))
 

+  [ Update: 1.0.14.36 improved this quite a bit (20-25%) by
+    eliminating useless work from PROPAGATE-FROM-SETS -- but as alluded
+    below, maybe we should be smarter about when to decide a derived
+    type is "good enough". ]
+

   This example could be solved with clever enough constraint
   propagation or with SSA, but consider
 
   This example could be solved with clever enough constraint
   propagation or with SSA, but consider
 

@@ -551,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

@@ -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

@@ -1612,22 +1618,6 @@ WORKAROUND:
   For some more details see comments for (define-alien-type-method
   (c-string :deport-gen) ...)  in host-c-call.lisp.
 
   For some more details see comments for (define-alien-type-method
   (c-string :deport-gen) ...)  in host-c-call.lisp.
 

-402: "DECLAIM DECLARATION does not inform the PCL code-walker"
-  reported by Vincent Arkesteijn:
-
-  (declaim (declaration foo))
-  (defgeneric bar (x))
-  (defmethod bar (x)
-    (declare (foo x))
-    x)
-
-  ==> WARNING: The declaration FOO is not understood by
-      SB-PCL::SPLIT-DECLARATIONS.
-      Please put FOO on one of the lists SB-PCL::*NON-VAR-DECLARATIONS*,
-      SB-PCL::*VAR-DECLARATIONS-WITH-ARG*, or
-      SB-PCL::*VAR-DECLARATIONS-WITHOUT-ARG*.
-      (Assuming it is a variable declaration without argument).
-

 403: FORMAT/PPRINT-LOGICAL-BLOCK of CONDITIONs ignoring *PRINT-CIRCLE*
   In sbcl-0.9.13.34,
     (defparameter *c*
 403: FORMAT/PPRINT-LOGICAL-BLOCK of CONDITIONs ignoring *PRINT-CIRCLE*
   In sbcl-0.9.13.34,
     (defparameter *c*

@@ -1729,6 +1719,10 @@ WORKAROUND:
                3: (SB-C::BOUND-FUNC ...)
                4: (SB-C::%SINGLE-FLOAT-DERIVE-TYPE-AUX ...)
 
                3: (SB-C::BOUND-FUNC ...)
                4: (SB-C::%SINGLE-FLOAT-DERIVE-TYPE-AUX ...)
 

+  These are now fixed, but (COERCE HUGE 'SINGLE-FLOAT) still signals a
+  type-error at runtime. The question is, should it instead signal a
+  floating-point overflow, or return an infinity?
+

 408: SUBTYPEP confusion re. OR of SATISFIES of not-yet-defined predicate
        As reported by Levente M\'{e}sz\'{a}ros sbcl-devel 2006-02-20,
                (aver (equal (multiple-value-list
 408: SUBTYPEP confusion re. OR of SATISFIES of not-yet-defined predicate
        As reported by Levente M\'{e}sz\'{a}ros sbcl-devel 2006-02-20,
                (aver (equal (multiple-value-list

@@ -1785,41 +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.
 

-413: type-errors in ROOM
-
-  (defvar *a* (make-array (expt 2 27)))
-  (room)
-
-  Causes a type-error on 32bit SBCL, as various byte-counts in ROOM
-  implementation overrun fixnums. 
-
-  This was fixed in 1.0.4.89, but the patch was reverted as it caused
-  ROOM to cons sufficiently to make running it in a loop deadly on
-  GENCGC: newly allocated objects survived to generation 1, where next
-  call to ROOM would see them, and allocate even more...
-
-  Reported by Faré Rideau on sbcl-devel.
-
-414: strange DISASSEMBLE warning
-
-  Compiling and disassembling 
-
-   (defun disassemble-source-form-bug (x y z)
-     (declare (optimize debug))
-     (list x y z))
-
-  Gives
-
-   WARNING: bogus form-number in form!  The source file has probably 
-   been changed too much to cope with.
-
-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)

@@ -1845,67 +1804,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.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:
 
 
 421: READ-CHAR-NO-HANG misbehaviour on Windows Console:
 

@@ -1923,3 +1841,59 @@ Which should be fixed, the IR1, or the backend?
 behaves ...erratically. Reported by Kevin Reid on sbcl-devel
 2007-07-06. (We don't _have_ to check things like this, but we
 generally try to check returns in safe code, so we should here too.)
 behaves ...erratically. Reported by Kevin Reid on sbcl-devel
 2007-07-06. (We don't _have_ to check things like this, but we
 generally try to check returns in safe code, so we should here too.)

+
+424: toplevel closures and *CHECK-CONSISTENCY*
+
+ The following breaks under COMPILE-FILE if *CHECK-CONSISTENCY* is true.
+
+  (let ((exported-symbols-alist
+         (loop for symbol being the external-symbols of :cl
+               collect (cons symbol
+                             (concatenate 'string
+                                          "#"
+                                          (string-downcase symbol))))))
+    (defun hyperdoc-lookup (symbol)
+      (cdr (assoc symbol exported-symbols-alist))))
+
+ (Test-case adapted from CL-PPCRE.)
+
+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