X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=e5b063c8361f6cf4237da5897f6604b135230b17;hb=0c4bd285c478056a52da8a8431a44736e2feb4da;hp=bcdc88688a8883eb3efe54373f687c375f5dfe3e;hpb=1b778d435773891979dab6d442c19f2b7b62b869;p=sbcl.git diff --git a/BUGS b/BUGS index bcdc886..e5b063c 100644 --- a/BUGS +++ b/BUGS @@ -382,6 +382,20 @@ WORKAROUND: Raymond Toy comments that this is tricky on the X86 since its FPU uses 80-bit precision internally. + Bruno Haible comments: + The values are those that are expected for an IEEE double-float + arithmetic. The problem appears to be that the rounding is not + IEEE on x86 compliant: namely, values are first rounded to 64 + bits mantissa precision, then only to 53 bits mantissa + precision. This gives different results than rounding to 53 bits + mantissa precision in a single step. + + The quick "fix", to permanently change the FPU control word from + 0x037f to 0x027f, will give problems with the fdlibm code that is + used for computing transcendental functions like sinh() etc. + so maybe we need to change the FPU control word to that for Lisp + code, and adjust it to the safe 0x037f for calls to C? + 124: As of version 0.pre7.14, SBCL's implementation of MACROLET makes the entire lexical environment at the point of MACROLET available @@ -616,12 +630,6 @@ WORKAROUND: The careful type of X is {2k} :-(. Is it really important to be able to work with unions of many intervals? -190: "PPC/Linux pipe? buffer? bug" - In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs - on the PPC/Linux platform, waiting for a zombie env process. This - is a classic symptom of buffer filling and deadlock, but it seems - only sporadically reproducible. - 191: "Miscellaneous PCL deficiencies" (reported by Alexey Dejneka sbcl-devel 2002-08-04) a. DEFCLASS does not inform the compiler about generated @@ -728,7 +736,6 @@ WORKAROUND: all of the arguments are circular is probably desireable). 213: "Sequence functions and type checking" - a. (fixed in 0.8.4.36) b. MAP, when given a type argument that is SUBTYPEP LIST, does not check that it will return a sequence of the given type. Fixing it along the same lines as the others (cf. work done around @@ -888,7 +895,6 @@ WORKAROUND: ; The variable Y is defined but never used. 245: bugs in disassembler - a. On X86 an immediate operand for IMUL is printed incorrectly. b. On X86 operand size prefix is not recognized. 251: @@ -1080,39 +1086,6 @@ WORKAROUND: (see also bug 117) -280: bogus WARNING about duplicate function definition - In sbcl-0.8.3 and sbcl-0.8.1.47, if BS.MIN is defined inline, - e.g. by - (declaim (inline bs.min)) - (defun bs.min (bases) nil) - before compiling the file below, the compiler warns - Duplicate definition for BS.MIN found in one static - unit (usually a file). - when compiling - (declaim (special *minus* *plus* *stagnant*)) - (defun b.*.min (&optional (x () xp) (y () yp) &rest rest) - (bs.min avec)) - (define-compiler-macro b.*.min (&rest rest) - `(bs.min ,@rest)) - (defun afish-d-rbd (pd) - (if *stagnant* - (b.*.min (foo-d-rbd *stagnant*)) - (multiple-value-bind (reduce-fn initial-value) - (etypecase pd - (list (values #'bs.min 0)) - (vector (values #'bs.min *plus*))) - (let ((cv-ks (cv (kpd.ks pd)))) - (funcall reduce-fn d-rbds))))) - (defun bfish-d-rbd (pd) - (if *stagnant* - (b.*.min (foo-d-rbd *stagnant*)) - (multiple-value-bind (reduce-fn initial-value) - (etypecase pd - (list (values #'bs.min *minus*)) - (vector (values #'bs.min 0))) - (let ((cv-ks (cv (kpd.ks pd)))) - (funcall reduce-fn d-rbds))))) - 281: COMPUTE-EFFECTIVE-METHOD error signalling. (slightly obscured by a non-0 default value for SB-PCL::*MAX-EMF-PRECOMPUTE-METHODS*) @@ -1216,18 +1189,6 @@ WORKAROUND: successive adds of integers to double-floats produces double-floats, so none of the type restrictions in the code is violated. -298: (aka PFD MISC.183) - Compiler fails on - - (defun foo () - (multiple-value-call #'bar - (ext) - (catch 'tag (return-from foo (int))))) - - This program violates "unknown values LVAR stack discipline": if INT - returns, values returned by (EXT) must be removed from under that of - (INT). - 300: (reported by Peter Graves) Function PEEK-CHAR checks PEEK-TYPE argument type only after having read a character. This is caused with EXPLICIT-CHECK attribute in DEFKNOWN. The similar problem @@ -1257,3 +1218,242 @@ WORKAROUND: (funcall (aref s ei) x y)) on sbcl-0.8.7.36/X86/Linux causes a BUG to be signalled: full call to SB-KERNEL:DATA-VECTOR-REF + +303: "nonlinear LVARs" (aka MISC.293) + (defun buu (x) + (multiple-value-call #'list + (block foo + (multiple-value-prog1 + (eval '(values :a :b :c)) + (catch 'bar + (if (> x 0) + (return-from foo + (eval `(if (> ,x 1) + 1 + (throw 'bar (values 3 4))))))))))) + + (BUU 1) returns garbage. + + 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) + (type (or (array cons) (array vector)) x)) + (elt (aref x 0) 0)) + (foo #((0))) => TYPE-ERROR + + relatedly, + + b.(subtypep + 'array + `(or + ,@(loop for x across sb-vm:*specialized-array-element-type-properties* + collect `(array ,(sb-vm:saetp-specifier x))))) + => NIL, T (when it should be T, T) + +308: "Characters without names" + (reported by Bruno Haible sbcl-devel "character names are missing" + 2004-04-19) + (graphic-char-p (code-char 255)) + => NIL + (char-name (code-char 255)) + => NIL + + SBCL is unsure of what to do about characters with codes in the + range 128-255. Currently they are treated as non-graphic, but don't + have names, which is not compliant with the standard. Various fixes + are possible, such as + * giving them names such as NON-ASCII-128; + * reducing CHAR-CODE-LIMIT to 127 (almost certainly unpopular); + * making the characters graphic (makes a certain amount of sense); + * biting the bullet and implementing Unicode (probably quite hard). + +309: "Dubious values for implementation limits" + (reported by Bruno Haible sbcl-devel "Incorrect value of + multiple-values-limit" 2004-04-19) + (values-list (make-list 1000000)), on x86/linux, signals a stack + exhaustion condition, despite MULTIPLE-VALUES-LIMIT being + significantly larger than 1000000. There are probably similar + dubious values for CALL-ARGUMENTS-LIMIT (see cmucl-help/cmucl-imp + 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. + ;; + ;; According to the HyperSpec 6.1.2.1.4, in for-as-equals-then, var is + ;; initialized to the result of evaluating form1. 6.1.7.2 says that + ;; initially clauses are evaluated in the loop prologue, which precedes all + ;; loop code except for the initial settings provided by with, for, or as. + (loop :for x = 0 :then (1+ x) + :for y = (1+ x) :then (ash y 1) + :for z :across #(1 3 9 27 81 243) + :for w = (+ x y z) + :initially (assert (zerop x)) :initially (assert (= 2 w)) + :until (>= w 100) :collect w) + Expected: (2 6 15 38) + Got: ERROR + +315: "no bounds check for access to displaced array" + reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP + test suite. + (locally (declare (optimize (safety 3) (speed 0))) + (let* ((x (make-array 10 :fill-pointer 4 :element-type 'character + :initial-element #\space :adjustable t)) + (y (make-array 10 :fill-pointer 4 :element-type 'character + :displaced-to x))) + (adjust-array x '(5)) + (char y 5))) + + SBCL fails this because (array-dimension y 0) return 10 even after the + adjustment, and hence the bounds-check passes. This is strictly + speaking legal, since the dictionary entry for ADJUST-ARRAY + says: + + "If A is displaced to B, the consequences are unspecified if B is + adjusted in such a way that it no longer has enough elements to + satisfy A." + + Should this be left as is, or should ARRAY-DIMENSION see if the + displaced-to array has shrunk too much and signal an error? An error + would probably be preferable, since a test of that form but with + (setf (char y 5) #\Space) potentially corrupts the heap and + certainly confuses the world if that string is used by C code. + +317: "FORMAT of floating point numbers" + reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP + test suite. + (format nil "~1F" 10) => "0." ; "10." expected + (format nil "~0F" 10) => "0." ; "10." expected + (format nil "~2F" 1234567.1) => "1000000." ; "1234567." expected + it would be nice if whatever fixed this also untangled the two + competing implementations of floating point printing (Steele and + White, and Burger and Dybvig) present in src/code/print.lisp + +318: "stack overflow in compiler warning with redefined class" + reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP + test suite. + (setq *print-pretty* nil) + (defstruct foo a) + (setf (find-class 'foo) nil) + (defstruct foo slot-1) + gives + ...#)) should work + for all positive integral . At present, it only works for up + to about 1024 (and similarly for signed-byte), so + (open "/dev/zero" :element-type '(unsigned-byte 1025)) + gives an error in sbcl-0.8.10. + +325: "CLOSE :ABORT T on supeseding streams" + Closing a stream opened with :IF-EXISTS :SUPERSEDE with :ABORT T leaves no + file on disk, even if one existed before opening. + + The illegality of this is not crystal clear, as the ANSI dictionary + entry for CLOSE says that when :ABORT is T superseded files are not + superseded (ie. the original should be restored), whereas the OPEN + entry says about :IF-EXISTS :SUPERSEDE "If possible, the + implementation should not destroy the old file until the new stream + is closed." -- implying that even though undesirable, early deletion + is legal. Restoring the original would none the less be the polite + thing to do. + +326: "*PRINT-CIRCLE* crosstalk between streams" + In sbcl-0.8.10.48 it's possible for *PRINT-CIRCLE* references to be + mixed between streams when output operations are intermingled closely + enough (as by doing output on S2 from within (PRINT-OBJECT X S1) in the + test case below), so that e.g. the references #2# appears on a stream + with no preceding #2= on that stream to define it (because the #2= was + sent to another stream). + (cl:in-package :cl-user) + (defstruct foo index) + (defparameter *foo* (make-foo :index 4)) + (defstruct bar) + (defparameter *bar* (make-bar)) + (defparameter *tangle* (list *foo* *bar* *foo*)) + (defmethod print-object ((foo foo) stream) + (let ((index (foo-index foo))) + (format *trace-output* + "~&-$- emitting FOO ~D, ambient *BAR*=~S~%" + index *bar*) + (format stream "[FOO ~D]" index)) + foo) + (let ((tsos (make-string-output-stream)) + (ssos (make-string-output-stream))) + (let ((*print-circle* t) + (*trace-output* tsos) + (*standard-output* ssos)) + (prin1 *tangle* *standard-output*)) + (let ((string (get-output-stream-string ssos))) + (unless (string= string "(#1=[FOO 4] #S(BAR) #1#)") + ;; In sbcl-0.8.10.48 STRING was "(#1=[FOO 4] #2# #1#)".:-( + (error "oops: ~S" string)))) + It might be straightforward to fix this by turning the + *CIRCULARITY-HASH-TABLE* and *CIRCULARITY-COUNTER* variables into + per-stream slots, but (1) it would probably be sort of messy faking + up the special variable binding semantics using UNWIND-PROTECT and + (2) it might be sort of a pain to test that no other bugs had been + introduced. + +327: "Lazy construction of CLOS classes from system classoids" + In a fresh SBCL, + (sb-mop:class-direct-subclasses (find-class 'pathname)) + returns NIL, despite the LOGICAL-PATHNAME class existing. However, + if we then do (find-class 'logical-pathname) and repeat the request + for direct subclasses, a list of the logical pathname class is + returned. (Though this particular example revealed the problem to + CSR, others have found that this gave consistent results for + PATHNAME, but not for SIMPLE-CONDITION.) + + Presumably the CLOS bootstrap process needs to iterate over + classoids (both structure- and condition-) to create CLOS classes + for them, so that this internal inconsistency does not arise? How + does this interact with the classoid hierarchy not perfectly + mirroring the class hierarchy? (e.g. INSTANCE?)