X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=38e54ee300f85cf2f86e8909f113bc41edfaa796;hb=40e3ba03d0e1b824e4d1ae75d74246b975b70964;hp=656648fef1ad2c82b3eec29cd6dc58d8d18ae572;hpb=96a139f451963981fc2419410f468bae1a5d25d2;p=sbcl.git diff --git a/BUGS b/BUGS index 656648f..38e54ee 100644 --- a/BUGS +++ b/BUGS @@ -730,6 +730,11 @@ WORKAROUND: (UNSIGNED-BYTE 8) will write to the stream one byte at a time, rather than writing the sequence in one go, leading to severe performance degradation. + As of sbcl-0.9.0.36, this is solved for fd-streams, so is less of a + problem in practice. (Fully fixing this would require adding a + ansi-stream-n-bout slot and associated methods to write a byte + sequence to ansi-stream, similar to the existing ansi-stream-sout + slot/functions.) 243: "STYLE-WARNING overenthusiasm for unused variables" (observed from clx compilation) @@ -919,24 +924,6 @@ WORKAROUND: (see also bug 117) -281: COMPUTE-EFFECTIVE-METHOD error signalling. - (slightly obscured by a non-0 default value for - SB-PCL::*MAX-EMF-PRECOMPUTE-METHODS*) - It would be natural for COMPUTE-EFFECTIVE-METHOD to signal errors - when it finds a method with invalid qualifiers. However, it - shouldn't signal errors when any such methods are not applicable to - the particular call being evaluated, and certainly it shouldn't when - simply precomputing effective methods that may never be called. - (setf sb-pcl::*max-emf-precompute-methods* 0) - (defgeneric foo (x) - (:method-combination +) - (:method ((x symbol)) 1) - (:method + ((x number)) x)) - (foo 1) -> ERROR, but should simply return 1 - - The issue seems to be that construction of a discriminating function - calls COMPUTE-EFFECTIVE-METHOD with methods that are not all applicable. - 283: Thread safety: libc functions There are places that we call unsafe-for-threading libc functions that we should find alternatives for, or put locks around. Known or @@ -1087,13 +1074,6 @@ WORKAROUND: around the same time regarding a call to LIST on sparc with 1000 arguments) and other implementation limit constants. -311: "Tokeniser not thread-safe" - (see also Robert Marlow sbcl-help "Multi threaded read chucking a - spak" 2004-04-19) - The tokenizer's use of *read-buffer* and *read-buffer-length* causes - spurious errors should two threads attempt to tokenise at the same - time. - 314: "LOOP :INITIALLY clauses and scope of initializers" reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP test suite, originally by Thomas F. Burdick. @@ -2058,10 +2038,81 @@ WORKAROUND: arrange_return_to_lisp_function(), but this looked hard to do in general without suffering from memory leaks. -378: floating-point exceptions not signalled on x86-64 - Floating point traps are currently not enabled on the x86-64 port. - This is true for at least overflow detection (as tested in - float.pure.lisp) and divide-by-zero. - 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. + +381: incautious calls to EQUAL in fasl dumping + Compiling + (frob #(#1=(a #1#))) + (frob #(#1=(b #1#))) + (frob #(#1=(a #1#))) + in sbcl-0.9.0 causes CONTROL-STACK-EXHAUSTED. My (WHN) impression + is that this follows from the use of (MAKE-HASH-TABLE :TEST 'EQUAL) + to detect sharing, in which case fixing it might require either + getting less ambitious about detecting shared list structure, or + implementing the moral equivalent of EQUAL hash tables in a + cycle-tolerant way. + +382: externalization unexpectedly changes array simplicity + COMPILE-FILE and LOAD + (defun foo () + (let ((x #.(make-array 4 :fill-pointer 0))) + (values (eval `(typep ',x 'simple-array)) + (typep x 'simple-array)))) + then (FOO) => T, NIL. + + Similar problems exist with SIMPLE-ARRAY-P, ARRAY-HEADER accessors + and all array dimension functions. + +383: ASH'ing non-constant zeros + Compiling + (lambda (b) + (declare (type (integer -2 14) b)) + (declare (ignorable b)) + (ash (imagpart b) 57)) + on PPC (and other platforms, presumably) gives an error during the + emission of FASH-ASH-LEFT/FIXNUM=>FIXNUM as the assembler attempts to + stuff a too-large constant into the immediate field of a PPC + instruction. Either the VOP should be fixed or the compiler should be + taught how to transform this case away, paying particular attention + to side-effects that might occur in the arguments to ASH. + +384: Compiler runaway on very large character types + + (compile nil '(lambda (x) + (declare (type (member #\a 1) x)) + (the (member 1 nil) x))) + + The types apparently normalize into a very large type, and the compiler + gets lost in REMOVE-DUPLICATES. Perhaps the latter should use + a better algorithm (one based on hash tables, say) on very long lists + when :TEST has its default value? + + A simpler example: + + (compile nil '(lambda (x) (the (not (eql #\a)) x))) + + (partially fixed in 0.9.3.1, but a better representation for these + types is needed.) + +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"). + +386: SunOS/x86 stack exhaustion handling broken + According to , the + stack exhaustion checking (implemented with a write-protected guard + page) does not work on SunOS/x86.