X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=0ad71a7026ce7ddd6344a3be8a3c06de1b2698b4;hb=c41cb4c87eae7b04f844dca5f7edb5086c5d2d68;hp=a4ed57fade321fc4c6aeff8c3c86d9c0b3234abb;hpb=ae1efb49d01b7f887b4e6bed741a01a28124c643;p=sbcl.git diff --git a/BUGS b/BUGS index a4ed57f..0ad71a7 100644 --- a/BUGS +++ b/BUGS @@ -84,24 +84,7 @@ WORKAROUND: an error may be signalled at read time and it would be good if SBCL did it. - c: Reading of not initialized slot sometimes causes SEGV (for inline - accessors it is fixed, but out-of-line still do not perform type - check). - - d: - (declaim (optimize (safety 3) (speed 1) (space 1))) - (defstruct foo - x y) - (defstruct (stringwise-foo (:include foo - (x "x" :type simple-string) - (y "y" :type simple-string)))) - (defparameter *stringwise-foo* - (make-stringwise-foo)) - (setf (foo-x *stringwise-foo*) 0) - (defun frob-stringwise-foo (sf) - (aref (stringwise-foo-x sf) 0)) - (frob-stringwise-foo *stringwise-foo*) - SEGV. + d: (fixed in 0.8.1.5) 7: The "compiling top-level form:" output ought to be condensed. @@ -187,12 +170,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) @@ -240,12 +217,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. @@ -293,34 +264,6 @@ WORKAROUND: holding... * is not equivalent to T in many cases, such as (VECTOR *) /= (VECTOR T). -94a: - Inconsistencies between derived and declared VALUES return types for - DEFUN aren't checked very well. E.g. the logic which successfully - catches problems like - (declaim (ftype (function (fixnum) float) foo)) - (defun foo (x) - (declare (type integer x)) - (values x)) ; wrong return type, detected, gives warning, good! - fails to catch - (declaim (ftype (function (t) (values t t)) bar)) - (defun bar (x) - (values x)) ; wrong number of return values, no warning, bad! - The cause of this is seems to be that (1) the internal function - VALUES-TYPES-EQUAL-OR-INTERSECT used to make the check handles its - arguments symmetrically, and (2) when the type checking code was - written back when when SBCL's code was still CMU CL, the intent - was that this case - (declaim (ftype (function (t) t) bar)) - (defun bar (x) - (values x x)) ; wrong number of return values; should give warning? - not be warned for, because a two-valued return value is considered - to be compatible with callers who expects a single value to be - returned. That intent is probably not appropriate for modern ANSI - Common Lisp, but fixing this might be complicated because of other - divergences between auld-style and new-style handling of - multiple-VALUES types. (Some issues related to this were discussed - on cmucl-imp at some length sometime in 2000.) - 95: The facility for dumping a running Lisp image to disk gets confused when run without the PURIFY option, and creates an unnecessarily large @@ -547,6 +490,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 @@ -554,6 +498,18 @@ WORKAROUND: conformance problem, since seems hard to construct useful code where it matters.) + b. + * (defun foo (x) + (declare (type (double-float -0d0) x)) + (declare (optimize speed)) + (+ x (sqrt (log (random 1d0))))) + debugger invoked on condition of type SIMPLE-ERROR: + bad thing to be a type specifier: ((COMPLEX + (DOUBLE-FLOAT 0.0d0 + #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY)) + #C(0.0d0 #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY) + #C(0.0d0 #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY)) + 146: Floating point errors are reported poorly. E.g. on x86 OpenBSD with sbcl-0.7.1, @@ -863,22 +819,7 @@ WORKAROUND: Then (FOO #\1 *STANDARD-OUTPUT*) signals type error. (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not - produce invalid code, but type checking is not accurate. Similar - problems exist with VALUES-TYPE-INTERSECTION.) - -220: - Sbcl 0.7.9 fails to compile - - (multiple-value-call #'list - (the integer (helper)) - nil) - - Type check for INTEGER, the result of which serves as the first - argument of M-V-C, is inserted after evaluation of NIL. So arguments - of M-V-C are pushed in the wrong order. As a temporary workaround - type checking was disabled for M-V-Cs in 0.7.9.13. A better solution - would be to put the check between evaluation of arguments, but it - could be tricky to check result types of PROG1, IF etc. + produce invalid code, but type checking is not accurate.) 233: bugs in constraint propagation a. @@ -1028,7 +969,7 @@ WORKAROUND: array types, there's no good way to tell it you're doing it intentionally so that it should shut up and just compile the code. - Another poblem is confusing error message "asserted type ARRAY + Another problem is confusing error message "asserted type ARRAY conflicts with derived type (VALUES SIMPLE-VECTOR &OPTIONAL)" during compiling (LAMBDA (V) (VALUES (SVREF V 0) (VECTOR-POP V))). @@ -1038,8 +979,199 @@ WORKAROUND: currently checks for complex arrays seem to be performed by callees.) -258: - (fixed in 0.8.1.3) +259: + (compile nil '(lambda () (aref (make-array 0) 0))) compiles without + warning. Analogous cases with the index and length being equal and + greater than 0 are warned for; the problem here seems to be that the + type required for an array reference of this type is (INTEGER 0 (0)) + which is canonicalized to NIL. + +260: + a. + (let* ((s (gensym)) + (t1 (specifier-type s))) + (eval `(defstruct ,s)) + (type= t1 (specifier-type s))) + => NIL, NIL + + (fixed in 0.8.1.24) + + b. The same for CSUBTYPEP. + +261: + * (let () (list (the (values &optional fixnum) (eval '(values))))) + debugger invoked on condition of type TYPE-ERROR: + The value NIL is not of type FIXNUM. + +262: "yet another bug in inline expansion of local functions" + Compiler fails on + + (defun foo (x y) + (declare (integer x y)) + (+ (block nil + (flet ((xyz (u) + (declare (integer u)) + (if (> (1+ (the unsigned-byte u)) 0) + (+ 1 u) + (return (+ 38 (cos (/ u 78))))))) + (declare (inline xyz)) + (return-from foo + (* (funcall (eval #'xyz) x) + (if (> x 30) + (funcall (if (> x 5) #'xyz #'identity) + (+ x 13)) + 38))))) + (sin (* x y)))) + + Urgh... It's time to write IR1-copier. + +265: + SB-EXT:RUN-PROGRAM is currently non-functional on Linux/PPC; + attempting to use it leads to segmentation violations. This is + probably because of a bogus implementation of + os_restore_fp_control(). + +266: + David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix + behaviour of streams with element-type (SIGNED-BYTE 8). The patch + looks reasonable, if not obviously correct; however, it caused the + PPC/Linux port to segfault during warm-init while loading + src/pcl/std-class.fasl. A workaround patch was made, but it would + be nice to understand why the first patch caused problems, and to + fix the cause if possible. + +268: "wrong free declaration scope" + The following code must signal type error: + + (locally (declare (optimize (safety 3))) + (flet ((foo (x &optional (y (car x))) + (declare (optimize (safety 0))) + (list x y))) + (funcall (eval #'foo) 1))) + +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"))) + +272: + All forms of GC hooks (including notifiers and finalisers) are currently + (since 0.8.0) broken for gencgc (i.e. x86) users + +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. + +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) + +277: + IGNORE/IGNORABLE declarations should be acceptable for symbol + macros. + +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. For the example above, the compiler does not issue a note. + +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))) + +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))))) DEFUNCT CATEGORIES OF BUGS IR1-#: