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
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)
(probably related to the bug 280.)
-313: "source-transforms are Lisp-1"
- (reported by Antonio Menezes Leitao on cll)
-
- PROPAGATE-FUN-CHANGE when checking, whether source transform is
- applicable, does not check variable/function original position of the
- COMBINATION-FUN. So the following functions are miscompiled:
-
- (defun foo (cadr) (if (functionp cadr) (funcall cadr 1) nil))
-
- (defvar cadr)
- (defun foo (cadr) (funcall (truly-the function cadr) 1))
-
- (check with (FOO #'IDENTITY))
+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.
+
+320: "shared to local slot in class redefinition"
+ reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
+ test suite.
+ ;; Shared slot becomes local.
+ ;; 4.3.6.1.: "The value of a slot that is specified as shared in
+ ;; the old class and as local in the new class is retained."
+ (multiple-value-bind (value condition)
+ (ignore-errors
+ (defclass foo85a ()
+ ((size :initarg :size :initform 1 :allocation :class)))
+ (defclass foo85b (foo85a) ())
+ (setq i (make-instance 'foo85b))
+ (defclass foo85a () ((size :initarg :size :initform 2) (other)))
+ (slot-value i 'size))
+ (list value (type-of condition)))
+ should return (1 NULL) but returns (2 NULL) in sbcl-0.8.10. See
+ ensuing discussion sbcl-devel for how to deal with this.
+
+321: "DEFINE-METHOD-COMBINATION lambda list parsing"
+ reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
+ test suite.
+ (define-method-combination w-args ()
+ ((method-list *))
+ (:arguments arg1 arg2 &aux (extra :extra))
+ `(progn ,@(mapcar (lambda (method) `(call-method ,method)) method-list)))
+ gives a (caught) compile-time error, which can be exposed by
+ (defgeneric mc-test-w-args (p1 p2 s)
+ (:method-combination w-args)
+ (:method ((p1 number) (p2 t) s)
+ (vector-push-extend (list 'number p1 p2) s))
+ (:method ((p1 string) (p2 t) s)
+ (vector-push-extend (list 'string p1 p2) s))
+ (:method ((p1 t) (p2 t) s) (vector-push-extend (list t p1 p2) s)))
+
+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.