X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=sidebyside;f=BUGS;h=ad13ce572cffc6a07fa93c8fe9b6c154d25686b8;hb=6a8fb906ba96395f2a60f821b2ec7649a2a3ae46;hp=527b0538568e88450413f09ccc06adb28eaa487d;hpb=711f965c40c13172cbc4b4dd381e6f638a1d6c34;p=sbcl.git diff --git a/BUGS b/BUGS index 527b053..ad13ce5 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. @@ -566,41 +549,6 @@ WORKAROUND: See also bugs #45.c and #183 -148: - In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file - (in-package :cl-user) - (defvar *thing*) - (defvar *zoom*) - (defstruct foo bar bletch) - (defun %zeep () - (labels ((kidify1 (kid) - ) - (kid-frob (kid) - (if *thing* - (setf sweptm - (m+ (frobnicate kid) - sweptm)) - (kidify1 kid)))) - (declare (inline kid-frob)) - (map nil - #'kid-frob - (the simple-vector (foo-bar perd))))) - fails with - debugger invoked on condition of type TYPE-ERROR: - The value NIL is not of type SB-C::NODE. - The location of this failure has moved around as various related - issues were cleaned up. As of sbcl-0.7.1.9, it occurs in - NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE. - - (Python LET-converts KIDIFY1 into KID-FROB, then tries to inline - expand KID-FROB into %ZEEP. Having partially done it, it sees a call - of KIDIFY1, which already does not exist. So it gives up on - expansion, leaving garbage consisting of infinished blocks of the - partially converted function.) - - (due to reordering of the compiler this example is compiled - successfully by 0.7.14, but the bug probably remains) - 162: (reported by Robert E. Brown 2002-04-16) When a function is called with too few arguments, causing the @@ -700,11 +648,9 @@ WORKAROUND: propagation or with SSA, but consider (let ((x 0)) - (loop (if (random-boolean) - (incf x 2) - (incf x 5)))) + (loop (incf x 2))) - The careful type of X is {2k+5n} :-(. Is it really important to be + The careful type of X is {2k} :-(. Is it really important to be able to work with unions of many intervals? 190: "PPC/Linux pipe? buffer? bug" @@ -1062,33 +1008,95 @@ WORKAROUND: This is a problem because the compiler emits optimization notes when you use a non-simple array, and without a type specifier for hairy - array types, there's no good way to tell it you're doing it + 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. -258: "TYPE-ERROR when recursive LABELS function is declared INLINE" - The compiler does emit a helpful - ; note: couldn't inline expand because expansion calls this - ; LET-converted local function: - ; "LABELS COMMON-LISP-USER::C.FROB" - but still shouldn't fail with a TYPE-ERROR - The value NIL is not of type SB-C::NODE. - when compiling - (cl:in-package :cl-user) - (declaim (optimize (safety 3) (speed 2) (space 1))) - (defvar *foo*) - (defvar *bar*) - (defun u-b-sra (x r ad0 &optional ad1 &rest ad-list) - (labels ((c.frob (c0) - (let () - (when *foo* - (vector-push-extend c0 *bar*)))) - (ad.frob (ad) - (if *foo* - (map nil #'ad.frob (the (vector t) *bar*)) - (dolist (b *bar*) - (c.frob b))))) - (declare (inline c.frob ad.frob)) ; 'til DYNAMIC-EXTENT - (ad.frob ad0))) + 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))). + + The last problem is that when type assertions are converted to type + checks, types are represented with type specifiers, so we could lose + complex attribute. (Now this is probably not important, because + currently checks for complex arrays seem to be performed by + callees.) + +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. + +262: + In 0.8.1.32: + + * (ensure-generic-function 'foo) + # + * (defmethod foo (x) x) + debugger invoked on condition of type SIMPLE-ERROR: + The generic function # takes 0 required + arguments; was asked to find a method with specializers (#) + + AMOP seems to say that it should work (first ADD-METHOD initializes + GF lambda list). + +264: + (reported by on #lisp 2003-07-16) + + (progv '(foo) '(1) + (eval '(symbol-macrolet ((foo 3)) + (declare (special foo)) + foo))) + + does not signal an error. + + (fixed in 0.8.1.37) + +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(). DEFUNCT CATEGORIES OF BUGS IR1-#: