X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=688b166181bee55cfced8fab477492679086b8f7;hb=61c18727668ff0c3263a3d363e609d4522d545cc;hp=19ac95c2f98bcadf9df15f43877d9716cba1e332;hpb=d59fb0b06768732835bf45638fbc04f516b9ae9b;p=sbcl.git diff --git a/BUGS b/BUGS index 19ac95c..688b166 100644 --- a/BUGS +++ b/BUGS @@ -32,8 +32,6 @@ have gone away (typically because they were fixed, but sometimes for other reasons, e.g. because they were moved elsewhere). -KNOWN BUGS OF NO SPECIAL CLASS: - 2: DEFSTRUCT almost certainly should overwrite the old LAYOUT information instead of just punting when a contradictory structure definition @@ -170,12 +168,6 @@ WORKAROUND: 45: a slew of floating-point-related errors reported by Peter Van Eynde on July 25, 2000: - b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT on the x86 is - bogus, and should probably be 1.4012985e-45. In SBCL, - (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller - than LEAST-POSITIVE-SHORT-FLOAT. Similar problems - exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT, - and LEAST-NEGATIVE-LONG-FLOAT. c: Many expressions generate floating infinity on x86/Linux: (/ 1 0.0) (/ 1 0.0d0) @@ -196,7 +188,10 @@ WORKAROUND: type safety errors reported by Peter Van Eynde July 25, 2000: k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is not a binary input stream, but instead cheerfully reads from - character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc"). + string-input streams, e.g. (MAKE-STRING-INPUT-STREAM "abc"). + [ Bug was reported as "from character streams", but in 0.8.3.10 we + get correct behaviour from (WITH-OPEN-FILE (i "/dev/zero") (READ-BYTE i)) ] + 60: The debugger LIST-LOCATIONS command doesn't work properly. @@ -223,12 +218,6 @@ WORKAROUND: crashes SBCL. In general tracing anything which is used in the implementation of TRACE is likely to have the same problem. -75: - As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000, - ANSI says that WITH-OUTPUT-TO-STRING should have a keyword - :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for - WITH-OUTPUT-TO-STRING. - 78: ANSI says in one place that type declarations can be abbreviated even when the type name is not a symbol, e.g. @@ -372,6 +361,8 @@ WORKAROUND: your pre-0.7.0 state of grace with #+sbcl (declaim (notinline find position find-if position-if)) ; bug 117.. + (see also bug 279) + 118: as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14: (= (FLOAT 1 DOUBLE-FLOAT-EPSILON) @@ -502,6 +493,7 @@ WORKAROUND: it took more than two minutes (but less than five) for me. 145: + a. ANSI allows types `(COMPLEX ,FOO) to use very hairy values for FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL COMPLEX implementation didn't deal with this, and hasn't been @@ -509,6 +501,8 @@ WORKAROUND: conformance problem, since seems hard to construct useful code where it matters.) + b. (fixed in 0.8.3.43) + 146: Floating point errors are reported poorly. E.g. on x86 OpenBSD with sbcl-0.7.1, @@ -541,6 +535,8 @@ WORKAROUND: isn't too surprising since there are many differences in stack implementation and GC conservatism between the X86 and other ports.) + This is probably the same bug as 216 + 167: In sbcl-0.7.3.11, compiling the (illegal) code (in-package :cl-user) @@ -757,20 +753,6 @@ WORKAROUND: (INTEGERP (CAR (MAKE-SEQUENCE '(CONS INTEGER *) 2))) can erroneously return T. -214: - SBCL 0.6.12.43 fails to compile - - (locally - (declare (optimize (inhibit-warnings 0) (compilation-speed 2))) - (flet ((foo (&key (x :vx x-p)) (list x x-p))) - (foo 1 2))) - - or a more simple example: - - (locally - (declare (optimize (inhibit-warnings 0) (compilation-speed 2))) - (lambda (x) (declare (fixnum x)) (if (< x 0) 0 (1- x)))) - 215: ":TEST-NOT handling by functions" a. FIND and POSITION currently signal errors when given non-NIL for both their :TEST and (deprecated) :TEST-NOT arguments, but by @@ -795,6 +777,8 @@ WORKAROUND: the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may not be the actual problem. (CMU CL 18c doesn't have problems with this.) + This is probably the same bug as 162 + 217: "Bad type operations with FUNCTION types" In sbcl.0.7.7: @@ -821,20 +805,6 @@ WORKAROUND: produce invalid code, but type checking is not accurate.) 233: bugs in constraint propagation - a. - (defun foo (x) - (declare (optimize (speed 2) (safety 3))) - (let ((y 0d0)) - (values - (the double-float x) - (setq y (+ x 1d0)) - (setq x 3d0) - (quux y (+ y 2d0) (* y 3d0))))) - (foo 4) => segmentation violation - - (see usage of CONTINUATION-ASSERTED-TYPE in USE-RESULT-CONSTRAINTS) - (see also bug 236) - b. (declaim (optimize (speed 2) (safety 3))) (defun foo (x y) @@ -1039,16 +1009,6 @@ WORKAROUND: be nice to understand why the first patch caused problems, and to fix the cause if possible. -267: - In - (defun fact (x i) - (if (= x 0) - i - (fact (1- x) (* x i)))) - sbcl does not convert the self-recursive call to a jump, though it - is allowed to by CLHS 3.2.2.3. CMUCL, however, does perform this - optimization. - 268: "wrong free declaration scope" The following code must signal type error: @@ -1058,7 +1018,229 @@ WORKAROUND: (list x y))) (funcall (eval #'foo) 1))) -DEFUNCT CATEGORIES OF BUGS - IR1-#: - These labels were used for bugs related to the old IR1 interpreter. - The # values reached 6 before the category was closed down. +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) + 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.