+ (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)
+ 288a: 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.)
+ 288b: The compiler still makes assumptions about cross-compilation-host
+ implementation of ANSI CL:
+ 288b1: Simple bit vectors are distinct from simple vectors (in
+ DEFINE-STORAGE-BASE and elsewhere). (Actually, I'm not *sure*
+ that things would really break if this weren't so, but I
+ strongly suspect that they would.)
+ 288b2: SINGLE-FLOAT is distinct from DOUBLE-FLOAT. (This is
+ in a sense just one aspect of bug 288a.)
+
+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.
+
+295:
+ From Paul Dietz:
+
+ (ash -1000000000000 -10000000000000000000) ==> 0 ;; should be -1
+
+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.
projects / sbcl.git / blobdiff