+ (defun foo (x)
+ (declare (integer x))
+ (declare (optimize speed))
+ (typecase x
+ (fixnum "hala")
+ (fixnum "buba")
+ (bignum "hip")
+ (t "zuz")))
+
+273:
+ Compilation of the following two forms causes "X is unbound" error:
+
+ (symbol-macrolet ((x pi))
+ (macrolet ((foo (y) (+ x y)))
+ (declaim (inline bar))
+ (defun bar (z)
+ (* z (foo 4)))))
+ (defun quux (z)
+ (bar z))
+
+ (See (COERCE (CDR X) 'FUNCTION) in IR1-CONVERT-INLINE-LAMBDA.)
+
+274:
+ CLHS says that type declaration of a symbol macro should not affect
+ its expansion, but in SBCL it does. (If you like magic and want to
+ fix it, don't forget to change all uses of MACROEXPAND to
+ MACROEXPAND*.)
+
+275:
+ The following code (taken from CLOCC) takes a lot of time to compile:
+
+ (defun foo (n)
+ (declare (type (integer 0 #.large-constant) n))
+ (expt 1/10 n))
+
+ (fixed in 0.8.2.51, but a test case would be good)
+
+278:
+ a.
+ (defun foo ()
+ (declare (optimize speed))
+ (loop for i of-type (integer 0) from 0 by 2 below 10
+ collect i))
+
+ uses generic arithmetic.
+
+ b. (fixed in 0.8.3.6)
+
+279: type propagation error -- correctly inferred type goes astray?
+ In sbcl-0.8.3 and sbcl-0.8.1.47, the warning
+ The binding of ABS-FOO is a (VALUES (INTEGER 0 0)
+ &OPTIONAL), not a (INTEGER 1 536870911)
+ is emitted when compiling this file:
+ (declaim (ftype (function ((integer 0 #.most-positive-fixnum))
+ (integer #.most-negative-fixnum 0))
+ foo))
+ (defun foo (x)
+ (- x))
+ (defun bar (x)
+ (let* (;; Uncomment this for a type mismatch warning indicating
+ ;; that the type of (FOO X) is correctly understood.
+ #+nil (fs-foo (float-sign (foo x)))
+ ;; Uncomment this for a type mismatch warning
+ ;; indicating that the type of (ABS (FOO X)) is
+ ;; correctly understood.
+ #+nil (fs-abs-foo (float-sign (abs (foo x))))
+ ;; something wrong with this one though
+ (abs-foo (abs (foo x))))
+ (declare (type (integer 1 100) abs-foo))
+ (print abs-foo)))
+
+ (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
+ strongly suspected problems, as of 0.8.3.10: please update this
+ bug instead of creating new ones
+
+ localtime() - called for timezone calculations in code/time.lisp
+
+284: Thread safety: special variables
+ There are lots of special variables in SBCL, and I feel sure that at
+ least some of them are indicative of potentially thread-unsafe
+ parts of the system. See doc/internals/notes/threading-specials
+
+286: "recursive known functions"
+ Self-call recognition conflicts with known function
+ recognition. Currently cross compiler and target COMPILE do not
+ recognize recursion, and in target compiler it can be disabled. We
+ can always disable it for known functions with RECURSIVE attribute,
+ but there remains a possibility of a function with a
+ (tail)-recursive simplification pass and transforms/VOPs for base
+ cases.
+
+287: PPC/Linux miscompilation or corruption in first GC
+ When the runtime is compiled with -O3 on certain PPC/Linux machines, a
+ segmentation fault is reported at the point of first triggered GC,
+ during the compilation of DEFSTRUCT WRAPPER. As a temporary workaround,
+ the runtime is no longer compiled with -O3 on PPC/Linux, but it is likely
+ that this merely obscures, not solves, the underlying problem; as and when
+ underlying problems are fixed, it would be worth trying again to provoke
+ this problem.
+
+288: fundamental cross-compilation issues (from old UGLINESS file)
+ Using host floating point numbers to represent target floating point
+ numbers, or host characters to represent target characters, is
+ theoretically shaky. (The characters are OK as long as the characters
+ are in the ANSI-guaranteed character set, though, so they aren't a
+ real problem as long as the sources don't need anything but that;
+ the floats are a real problem.)
+
+289: "type checking and source-transforms"
+ a.
+ (block nil (let () (funcall #'+ (eval 'nil) (eval '1) (return :good))))
+ signals type error.
+
+ Our policy is to check argument types at the moment of a call. It
+ disagrees with ANSI, which says that type assertions are put
+ immediately onto argument expressions, but is easier to implement in
+ IR1 and is more compatible to type inference, inline expansion,
+ etc. IR1-transforms automatically keep this policy, but source
+ transforms for associative functions (such as +), being applied
+ during IR1-convertion, do not. It may be tolerable for direct calls
+ (+ x y z), but for (FUNCALL #'+ x y z) it is non-conformant.
+
+ b. Another aspect of this problem is efficiency. [x y + z +]
+ requires less registers than [x y z + +]. This transformation is
+ currently performed with source transforms, but it would be good to
+ also perform it in IR1 optimization phase.
+
+290: Alpha floating point and denormalized traps
+ In SBCL 0.8.3.6x on the alpha, we work around what appears to be a
+ hardware or kernel deficiency: the status of the enable/disable
+ denormalized-float traps bit seems to be ambiguous; by the time we
+ get to os_restore_fp_control after a trap, denormalized traps seem
+ to be enabled. Since we don't want a trap every time someone uses a
+ denormalized float, in general, we mask out that bit when we restore
+ the control word; however, this clobbers any change the user might
+ have made.
+
+296:
+ (reported by Adam Warner, sbcl-devel 2003-09-23)
+
+ The --load toplevel argument does not perform any sanitization of its
+ argument. As a result, files with Lisp pathname pattern characters
+ (#\* or #\?, for instance) or quotation marks can cause the system
+ to perform arbitrary behaviour.
+
+297:
+ LOOP with non-constant arithmetic step clauses suffers from overzealous
+ type constraint: code of the form
+ (loop for d of-type double-float from 0d0 to 10d0 by x collect d)
+ compiles to a type restriction on X of (AND DOUBLE-FLOAT (REAL
+ (0))). However, an integral value of X should be legal, because
+ successive adds of integers to double-floats produces double-floats,
+ so none of the type restrictions in the code is violated.
+
+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
+ exists with =, /=, <, >, <=, >=. They were fixed, but it is probably
+ less error prone to have EXPLICIT-CHECK be a local declaration,
+ being put into the definition, instead of an attribute being kept in
+ a separate file; maybe also put it into SB-EXT?
+
+301: ARRAY-SIMPLE-=-TYPE-METHOD breaks on corner cases which can arise
+ in NOTE-ASSUMED-TYPES
+ In sbcl-0.8.7.32, compiling the file
+ (defun foo (x y)
+ (declare (type integer x))
+ (declare (type (vector (or hash-table bit)) y))
+ (bletch 2 y))
+ (defun bar (x y)
+ (declare (type integer x))
+ (declare (type (simple-array base (2)) y))
+ (bletch 1 y))
+ gives the error
+ failed AVER: "(NOT (AND (NOT EQUALP) CERTAINP))"
+
+302: Undefined type messes up DATA-VECTOR-REF expansion.
+ Compiling this file
+ (defun dis (s ei x y)
+ (declare (type (simple-array function (2)) s) (type ei ei))
+ (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.
+ ;; <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
+
+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.
+
+328: "Profiling generic functions", transplanted from #241
+ (from tonyms on #lisp IRC 2003-02-25)
+ In sbcl-0.7.12.55, typing
+ (defclass foo () ((bar :accessor foo-bar)))
+ (profile foo-bar)
+ (unintern 'foo-bar)
+ (defclass foo () ((bar :accessor foo-bar)))
+ gives the error message
+ "#:FOO-BAR already names an ordinary function or a macro."
projects / sbcl.git / blobdiff