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.
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
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
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"
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.
257:
Complex array type does not have corresponding type specifier.
+ 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
+ intentionally so that it should shut up and just compile the code.
+
+ 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.
+
+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.
+
+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:
+
+ (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.
+
DEFUNCT CATEGORIES OF BUGS
IR1-#:
These labels were used for bugs related to the old IR1 interpreter.
projects / sbcl.git / blobdiff