+269:
+ SCALE-FLOAT should accept any integer for its second argument.
+
+270:
+ In the following function constraint propagator optimizes nothing:
+
+ (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)
+
+276:
+ (defmethod fee ((x fixnum))
+ (setq x (/ x 2))
+ x)
+ (fee 1) => type error
+
+ (taken from CLOCC)
+
+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)
+
+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*)
+ 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.
projects / sbcl.git / blobdiff