X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=d7ecde8dabd4f75f2770419e017052a8b4f4ee45;hb=53f576d7d796e37a9c51c3c3296341458f046c44;hp=de893455681e6fe603929a465d8d2f57e8d4c0af;hpb=389b5755b2eab960c1f4c14045a26de5dbd510c1;p=sbcl.git diff --git a/BUGS b/BUGS index de89345..d7ecde8 100644 --- 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.) + (Can't reproduce on x86 linux as of 1.0.20.23 - MGL) + 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. -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 @@ -632,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.) + (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" @@ -1051,7 +1050,7 @@ WORKAROUND: (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. @@ -1134,25 +1133,6 @@ WORKAROUND: 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))) @@ -1397,30 +1377,6 @@ WORKAROUND: Expected: ERROR Got: # -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 @@ -1458,19 +1414,6 @@ WORKAROUND: 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 () @@ -1516,6 +1459,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"). + (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 , the @@ -1778,13 +1723,6 @@ WORKAROUND: 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) @@ -1810,74 +1748,26 @@ WORKAROUND: 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)) - (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)))))) + ((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-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 - - (+ ) ; uses double-precision - (+ (FLOAT )) ; 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? + 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: @@ -1911,60 +1801,26 @@ 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) - # - * (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))))) +431: alien strucure redefinition doesn't work as expected + fixed in 1.0.21.29