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
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
(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*)
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
collect `(array ,(sb-vm:saetp-specifier x)))))
=> NIL, T (when it should be T, T)
-307: "Problem in obsolete instance protocol"
- (reported by Bruno Haible as the fourth problem in sbcl-devel
- "installing sbcl" 2004-04-15)
-
- (progn
- (defclass foo92b (foo92a) ((s :initarg :s)))
- (defclass foo92a () ())
- (let ((x (make-instance 'foo92b :s 5)) (update-counter 0))
- (defclass foo92b (foo92a) ((s) (s1) (s2))) ; still subclass of foo92a
- (slot-value x 's)
- (defmethod update-instance-for-redefined-class
- ((object foo92b) added-slots discarded-slots plist &rest initargs)
- (incf update-counter))
- (make-instances-obsolete 'foo92a)
- (slot-value x 's)
- update-counter))
- => 0 ; should be 1
-
308: "Characters without names"
(reported by Bruno Haible sbcl-devel "character names are missing"
2004-04-19)
around the same time regarding a call to LIST on sparc with 1000
arguments) and other implementation limit constants.
-310: "Floating point printing inaccuracy"
- (reported by Bruno Haible sbcl-devel "print-read consistency for
- floating point numbers" 2004-04-19)
- (let ((x (/ -9.349640046247849d-21 -9.381494249123696d-11)))
- (let ((y (read-from-string (write-to-string x :readably t))))
- (eql x y)))
- should return T but, as of sbcl-0.8.9.51, returns NIL.
-
- That this is a bug in the printer is demonstrated by
- (setq x1 (float -5496527/100000000000000000))
- (setq x2 (float -54965272/1000000000000000000))
- (integer-decode-float x1) => 15842660 -58 -1
- (integer-decode-float x2) => 15842661 -58 -1
- (prin1-to-string x1) => "-5.496527e-11"
- (prin1-to-string x2) => "-5.496527e-11" ; should be different!
-
- Note also the following comment from src/code/print.lisp:
- ;;; NOTE: When a number is to be printed in exponential format, it is
- ;;; scaled in floating point. Since precision may be lost in this
- ;;; process, the guaranteed accuracy properties of FLONUM-TO-STRING
- ;;; are lost. The difficulty is that FLONUM-TO-STRING performs
- ;;; extensive computations with integers of similar magnitude to that
- ;;; of the number being printed. For large exponents, the bignums
- ;;; really get out of hand. If bignum arithmetic becomes reasonably
- ;;; fast and the exponent range is not too large, then it might become
- ;;; attractive to handle exponential notation with the same accuracy
- ;;; as non-exponential notation, using the method described in the
- ;;; Steele and White paper.
-
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.
+ ;; <http://www.lisp.org/HyperSpec/Body/sec_6-1-7-2.html>
+ ;; 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 0.8.10 elides the bounds check somewhere along the line, and
+ returns #\Nul (where an error would be much 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
+ ...#<SB-KERNEL:STRUCTURE-CLASSOID #<SB-KERNEL:STRUCTURE-CLASSOID #<SB-KERNEL:STRUCTURE-CLASSOID #<SB-KERNEL:STRUCTUREControl stack guard page temporarily disabled: proceed with caution
+ (it's not really clear what it should give: is (SETF FIND-CLASS)
+ meant to be enough to delete structure classes from the system?
+ Giving a stack overflow is definitely suboptimal, though.)
+
+319: "backquote with comma inside array"
+ reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
+ test suite.
+ (read-from-string "`#1A(1 2 ,(+ 2 2) 4)")
+ gives
+ #(1 2 ((SB-IMPL::|,|) + 2 2) 4)
+ which probably isn't intentional.
+
+323: "REPLACE, BIT-BASH and large strings"
+ The transform for REPLACE on simple-base-strings uses BIT-BASH, which
+ at present has an upper limit in size. Consequently, in sbcl-0.8.10
+ (defun foo ()
+ (declare (optimize speed (safety 1)))
+ (let ((x (make-string 140000000))
+ (y (make-string 140000000)))
+ (length (replace x y))))
+ (foo)
+ gives
+ debugger invoked on a TYPE-ERROR in thread 2412:
+ The value 1120000000 is not of type (MOD 536870911).
+ (see also "more and better sequence transforms" sbcl-devel 2004-05-10)
+
+324: "STREAMs and :ELEMENT-TYPE with large bytesize"
+ In theory, (open foo :element-type '(unsigned-byte <x>)) should work
+ for all positive integral <x>. At present, it only works for <x> 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?)
projects / sbcl.git / blobdiff