X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=38e54ee300f85cf2f86e8909f113bc41edfaa796;hb=40e3ba03d0e1b824e4d1ae75d74246b975b70964;hp=13c82f1e43224cb16ebd48f007bee497f03ae411;hpb=bea5b384106a6734a4b280a76e8ebdd4d51b5323;p=sbcl.git diff --git a/BUGS b/BUGS index 13c82f1..38e54ee 100644 --- a/BUGS +++ b/BUGS @@ -585,18 +585,6 @@ WORKAROUND: 211: "keywords processing" a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd number of keyword arguments. - e. Compiling - - (flet ((foo (&key y) (list y))) - (list (foo :y 1 :y 2))) - - issues confusing message - - ; in: LAMBDA NIL - ; (FOO :Y 1 :Y 2) - ; - ; caught STYLE-WARNING: - ; The variable #:G15 is defined but never used. 212: "Sequence functions and circular arguments" COERCE, MERGE and CONCATENATE go into an infinite loop when given @@ -742,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) @@ -887,6 +880,14 @@ WORKAROUND: (fixed in 0.8.2.51, but a test case would be good) +276: + b. The same as in a., but using MULTIPLE-VALUE-SETQ instead of SETQ. + c. (defvar *faa*) + (defmethod faa ((*faa* double-float)) + (set '*faa* (when (< *faa* 0) (- *faa*))) + (1+ *faa*)) + (faa 1d0) => type error + 278: a. (defun foo () @@ -923,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 @@ -1065,17 +1048,6 @@ WORKAROUND: The problem is that both EVALs sequentially write to the same LVAR. -305: - (Reported by Dave Roberts.) - Local INLINE/NOTINLINE declaration removes local FTYPE declaration: - - (defun quux (x) - (declare (ftype (function () (integer 0 10)) fee) - (inline fee)) - (1+ (fee))) - - uses generic arithmetic with INLINE and fixnum without. - 306: "Imprecise unions of array types" a.(defun foo (x) (declare (optimize speed) @@ -1102,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. @@ -1515,6 +1480,10 @@ WORKAROUND: (used on non-x86 platforms) being a more complete solution then what is done on x86. + On x86/linux large portions of tests/debug.impure.lisp have been commented + out as failures. The probable culprit for these problems is in x86-call-context + (things work fine on x86/freebsd). + More generally, the debugger internals suffer from excessive x86/non-x86 conditionalization and OAOOMization: refactoring the common parts would be good. @@ -1528,7 +1497,11 @@ WORKAROUND: (sparc and x86 at least) Since SBCL 0.8.20.1 this is hidden unless *SHOW-ENTRY-POINT-DETAILS* - is true. + is true (instead there appear two TEST frames at least on ppc). The + underlying cause seems to be that SB-C::TAIL-ANNOTATE will not merge + the tail-call for the XEP, since Python has by that time proved that + the function can never return; same happens if the function holds an + unconditional call to ERROR. 355: change-class of generic-function (reported by Bruno Haible) @@ -2026,20 +1999,120 @@ WORKAROUND: #.SB-EXT:SINGLE/DOUBLE-FLOAT-POSITIVE-INFINITY. These tests have been disabled on Darwin for now. -373: profiling issues on ppc/darwin - The following bit from smoke.impure.lisp fails on ppc/darwin: - (progn - (defun profiled-fun () - (random 1d0)) - (profile profiled-fun) - (loop repeat 100000 do (profiled-fun)) - (report)) - dropping into the debugger with a TYPE-ERROR: - The value -1073741382 is not of type UNSIGNED-BYTE. - The test has been disabled on Darwin till the bug is fixed. - 374: BIT-AND problem on ppc/darwin: The BIT-AND test in bit-vector.impure-cload.lisp results in fatal error encountered in SBCL pid 8356: GC invariant lost, file "gc-common.c", line 605 on ppc/darwin. Test disabled for the duration. + +375: MISC.555 + (compile nil '(lambda (p1) + (declare (optimize (speed 1) (safety 2) (debug 2) (space 0)) + (type keyword p1)) + (keywordp p1))) + + fails on hairy type check in IR2. + + 1. KEYWORDP is MAYBE-INLINE expanded (before TYPEP-like + transformation could eliminate it). + + 2. From the only call of KEYWORDP the type of its argument is + derived to be KEYWORD. + + 2. Type check for P1 is generated; it uses KEYWORDP to perform the + check, and so references the local function; from the KEYWORDP + argument type new CAST to KEYWORD is generated. The compiler + loops forever. + +377: Memory fault error reporting + On those architectures where :C-STACK-IS-CONTROL-STACK is in + *FEATURES*, we handle SIG_MEMORY_FAULT (SEGV or BUS) on an altstack, + so we cannot handle the signal directly (as in interrupt_handle_now()) + in the case when the signal comes from some external agent (the user + using kill(1), or a fault in some foreign code, for instance). As + of sbcl-0.8.20.20, this is fixed by calling + arrange_return_to_lisp_function() to a new error-signalling + function, but as a result the error reporting is poor: we cannot + even tell the user at which address the fault occurred. We should + arrange such that arguments can be passed to the function called from + arrange_return_to_lisp_function(), but this looked hard to do in + general without suffering from memory leaks. + +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.