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.
See also bugs #45.c and #183
-148:
- COMPILE-FILE on the file
- (defun u-b-sra (ad0)
- (declare (special *foo* *bar*))
- (declare (optimize (safety 3) (speed 2) (space 1)))
- (labels ((c.frob ())
- (ad.frob (ad)
- (if *foo*
- (mapc #'ad.frob *bar*)
- (dolist (b *bar*)
- (c.frob)))))
- (declare (inline c.frob ad.frob))
- (ad.frob ad0)))
- fails with
- debugger invoked on condition of type TYPE-ERROR:
- The value NIL is not of type SB-C::NODE.
-
- (Python LET-converts C.FROB into AD.FROB, then tries to inline
- expand AD.FROB. Having partially done it, it sees a call of C.FROB,
- which already does not exist. So it gives up on expansion, leaving
- garbage consisting of infinished blocks of the partially converted
- function.)
-
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"
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))).
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.
+
DEFUNCT CATEGORIES OF BUGS
IR1-#:
These labels were used for bugs related to the old IR1 interpreter.