- produce invalid code, but type checking is not accurate. Similar
- problems exist with VALUES-TYPE-INTERSECTION.)
-
-218: "VALUES type specifier semantics"
- (THE (VALUES ...) ...) in safe code discards extra values.
-
- (defun test (x y) (the (values integer) (truncate x y)))
- (test 10 4) => 2
-
-219: "DEFINE-COMPILER-MACRO in non-toplevel contexts evaluated at compile-time"
- In sbcl-0.7.9:
-
- * (defun foo (x)
- (when x
- (define-compiler-macro bar (&whole whole)
- (declare (ignore whole))
- (print "expanding compiler macro")
- 1)))
- FOO
- * (defun baz (x) (bar))
- [ ... ]
- "expanding compiler macro"
- BAZ
- * (baz t)
- 1
-
-220:
- Sbcl 0.7.9 fails to compile
-
- (multiple-value-call #'list
- (the integer (helper))
- nil)
-
- Type check for INTEGER is inserted, 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 a check between evaluation of
- arguments, but it could be tricky to check result types of PROG1, IF
- etc.
-
-222: "environment problems in PCL"
- Evaluating
-
- (symbol-macrolet ((x 1))
- (defmethod foo (z)
- (macrolet ((ml (form) `(progn ,form ,x)))
- (ml (print x)))))
-
- causes
-
- debugger invoked on condition of type UNBOUND-VARIABLE:
- The variable X is unbound.
-
-223: "(SETF FDEFINITION) and #' semantics broken for wrappers"
- Although this
- (defun foo (x)
- (print x))
- (defun traced (fn)
- (lambda (&rest rest)
- (format t "~&about to call ~S on ~S~%" fn rest)
- (apply fn rest)
- (format t "~&returned from ~S~%" fn)))
- (setf (fdefinition 'foo)
- (traced #'foo))
- (foo 11)
- does what one would expect, this
- (defun bar (x)
- (print x))
- (let ((bar0 #'bar))
- (setf (fdefinition 'bar)
- (lambda (&rest rest)
- (format t "~&about to enter BAR ~S~%" rest)
- (apply bar0 rest)
- (format t "~&back from BAR~%"))))
- (bar 12)
- recurses endlessly in sbcl-0.7.9.32. (Or it works if #' and
- FDEFINITION are replaced by SYMBOL-FUNCTION.)
-
-224:
- SBCL 0.7.8 fails to compile
- (localy (declare (optimize (safety 3)))
- (ignore-errors (progn (values-list (car (list '(1 . 2)))) t)))
- (the LOCALY there is not a typo; any unknown function (e.g. FROB)
- will do).
-
-226: "AVER failure in COMPILE-FILE of clocc-ansi-test/tests.lisp"
- (APD points out that this seems to be another symptom of bug #115.)
- sbcl-0.7.9.43 dies with failed AVER "(EQ (TN-PHYSENV TN) TN-ENV)" when
- trying to compile clocc-ansi-test/tests.lisp. sbcl-0.7.9.31 was able to
- to compile it. A smaller test case exhibiting the same problem is
- (declaim (optimize (speed 0) (safety 3) (debug 3)))
- (defun c-a-p ()
- (flet ((safe-format (stream string &rest r)
- (unless (ignore-errors (progn
- (apply #'format stream string r)
- t))
- (format stream "~&foo ~S" string))))
- (cond
- ((eq my-result :ERROR)
- (cond
- ((ignore-errors (typep condition result))
- (safe-format t "~&bar ~S" result))
- (t
- (safe-format t "~&baz ~S (~A) ~S" condition condition result)))))))
-
-227: "compiler bewilderment with adjustable vectors and COPY-SEQ"
- (fixed in sbcl-0.7.9.65)
-
-228: "function-lambda-expression problems"
- in sbcl-0.7.9.6x, from the REPL:
- * (progn (declaim (inline foo)) (defun foo (x) x))
- FOO
- * (function-lambda-expression #'foo)
- (SB-C:LAMBDA-WITH-LEXENV NIL NIL NIL (X) (BLOCK FOO X)), NIL, FOO
- but this first return value is not suitable for input to FUNCTION or
- COMPILE, as required by ANSI.
-
-229:
- (subtypep 'function '(function)) => nil, t.
+ 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)
+ (if (typep (prog1 x (setq x y)) 'double-float)
+ (+ x 1d0)
+ (+ x 2)))
+ (foo 1d0 5) => segmentation violation
+
+235: "type system and inline expansion"
+ a.
+ (declaim (ftype (function (cons) number) acc))
+ (declaim (inline acc))
+ (defun acc (c)
+ (the number (car c)))
+
+ (defun foo (x y)
+ (values (locally (declare (optimize (safety 0)))
+ (acc x))
+ (locally (declare (optimize (safety 3)))
+ (acc y))))
+
+ (foo '(nil) '(t)) => NIL, T.
+
+237: "Environment arguments to type functions"
+ a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
+ UPGRADED-COMPLEX-PART-TYPE now have an optional environment
+ argument, but they ignore it completely. This is almost
+ certainly not correct.
+ b. Also, the compiler's optimizers for TYPEP have not been informed
+ about the new argument; consequently, they will not transform
+ calls of the form (TYPEP 1 'INTEGER NIL), even though this is
+ just as optimizeable as (TYPEP 1 'INTEGER).
+
+238: "REPL compiler overenthusiasm for CLOS code"
+ From the REPL,
+ * (defclass foo () ())
+ * (defmethod bar ((x foo) (foo foo)) (call-next-method))
+ causes approximately 100 lines of code deletion notes. Some
+ discussion on this issue happened under the title 'Three "interesting"
+ bugs in PCL', resulting in a fix for this oververbosity from the
+ compiler proper; however, the problem persists in the interactor
+ because the notion of original source is not preserved: for the
+ compiler, the original source of the above expression is (DEFMETHOD
+ BAR ((X FOO) (FOO FOO)) (CALL-NEXT-METHOD)), while by the time the
+ compiler gets its hands on the code needing compilation from the REPL,
+ it has been macroexpanded several times.
+
+ A symptom of the same underlying problem, reported by Tony Martinez:
+ * (handler-case
+ (with-input-from-string (*query-io* " no")
+ (yes-or-no-p))
+ (simple-type-error () 'error))
+ ; in: LAMBDA NIL
+ ; (SB-KERNEL:FLOAT-WAIT)
+ ;
+ ; note: deleting unreachable code
+ ; compilation unit finished
+ ; printed 1 note
+
+241: "DEFCLASS mysteriously remembers uninterned accessor names."
+ (from tonyms on #lisp IRC 2003-02-25)
+ In sbcl-0.7.12.55, typing
+ (defclass foo () ((bar :accessor foo-bar)))
+ (profile foo-bar)
+ (unintern 'foo-bar)
+ (defclass foo () ((bar :accessor foo-bar)))
+ gives the error message
+ "#:FOO-BAR already names an ordinary function or a macro."
+ So it's somehow checking the uninterned old accessor name instead
+ of the new requested accessor name, which seems broken to me (WHN).
+
+242: "WRITE-SEQUENCE suboptimality"
+ (observed from clx performance)
+ In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type
+ (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) on a stream with element-type
+ (UNSIGNED-BYTE 8) will write to the stream one byte at a time,
+ rather than writing the sequence in one go, leading to severe
+ performance degradation.
+
+243: "STYLE-WARNING overenthusiasm for unused variables"
+ (observed from clx compilation)
+ In sbcl-0.7.14, in the presence of the macros
+ (DEFMACRO FOO (X) `(BAR ,X))
+ (DEFMACRO BAR (X) (DECLARE (IGNORABLE X)) 'NIL)
+ somewhat surprising style warnings are emitted for
+ (COMPILE NIL '(LAMBDA (Y) (FOO Y))):
+ ; in: LAMBDA (Y)
+ ; (LAMBDA (Y) (FOO Y))
+ ;
+ ; caught STYLE-WARNING:
+ ; The variable Y is defined but never used.
+
+245: bugs in disassembler
+ a. On X86 an immediate operand for IMUL is printed incorrectly.
+ b. On X86 operand size prefix is not recognized.
+
+248: "reporting errors in type specifier syntax"
+ (TYPEP 1 '(SYMBOL NIL)) says something about "unknown type
+ specifier".
+
+251:
+ (defun foo (&key (a :x))
+ (declare (fixnum a))
+ a)
+
+ does not cause a warning. (BTW: old SBCL issued a warning, but for a
+ function, which was never called!)
+
+256:
+ Compiler does not emit warnings for
+
+ a. (lambda () (svref (make-array 8 :adjustable t) 1))
+
+ b. (lambda (x)
+ (list (let ((y (the real x)))
+ (unless (floatp y) (error ""))
+ y)
+ (integer-length x)))
+
+ c. (lambda (x)
+ (declare (optimize (debug 0)))
+ (declare (type vector x))
+ (list (fill-pointer x)
+ (svref x 1)))
+
+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)))