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
; 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:
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
The problem is that both EVALs sequentially write to the same LVAR.
-304:
- (Thanks to Dave Roberts.)
-
- (defun foo (a i)
- (declare (optimize (speed 3) (safety 0) (space 0) (debug 0)))
- (declare (type (alien (* (unsigned 8))) a)
- (type (unsigned-byte 32) i))
- (deref a i))
-
- Under recent enough SBCL the output code contains (TWO-ARG-/ (* x 8)
- 8). (Two problems: opaque CAST and modular functions).
-
305:
(Reported by Dave Roberts.)
Local INLINE/NOTINLINE declaration removes local FTYPE declaration:
(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.
+
+312:
+ (reported by Jon Dyte)
+ SBCL issues a warning "Duplicate definition of FOO" compiling
+
+ (declaim (inline foo))
+ (defun foo (x)
+ (1+ x))
+ (defun bar (y)
+ (list (foo y) (if (> y 1) (funcall (if (> y 0) #'foo #'identity) y))))
+
+ (probably related to the bug 280.)
+
+313: "source-transforms are Lisp-1"
+ (fixed in 0.8.10.2)
+
+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.
+
+316: "SHIFTF and multiple values"
+ reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
+ test suite.
+ (shiftf (values x y) (values y x))
+ gives an error in sbcl-0.8.10.
+
+ Parts of the explanation of SHIFTF in ANSI CL talk about multiple
+ store variables, and the X3J13 vote
+ SETF-MULTIPLE-STORE-VARIABLES:ALLOW also says that SHIFTF should
+ support multiple value places.
+
+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)))
+
+322: "DEFSTRUCT :TYPE LIST predicate and improper lists"
+ reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
+ test suite.
+ (defstruct (a (:type list) (:initial-offset 5) :named))
+ (defstruct (b (:type list) (:initial-offset 2) :named (:include a)))
+ (b-p (list* nil nil nil nil nil 'foo73 nil 'tail))
+ gives an error in sbcl-0.8.10