X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=f58784a35a1b3932dadd1ed098a85bd5ad9f3e20;hb=ed72064bbc8203d70526388e90d6858c28a6db25;hp=503fdc4e43b501ee80713c32e58f5dd8c060625d;hpb=3ca67be9529e3f2800facea80903062af79f870f;p=sbcl.git diff --git a/BUGS b/BUGS index 503fdc4..f58784a 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: @@ -479,6 +481,11 @@ WORKAROUND: (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 @@ -551,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 @@ -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.) + (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" @@ -1046,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. @@ -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"). + (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 @@ -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. -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* @@ -1729,6 +1719,10 @@ WORKAROUND: 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 @@ -1785,28 +1779,6 @@ WORKAROUND: 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. - -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) @@ -1832,67 +1804,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 - - (+ ) ; 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? + ((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: @@ -1910,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.) + +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