(print (incf start 22))
(print (incf start 26))))))
+ [ Update: 1.0.14.36 improved this quite a bit (20-25%) by
+ eliminating useless work from PROPAGATE-FROM-SETS -- but as alluded
+ below, maybe we should be smarter about when to decide a derived
+ type is "good enough". ]
+
This example could be solved with clever enough constraint
propagation or with SSA, but consider
3: (SB-C::BOUND-FUNC ...)
4: (SB-C::%SINGLE-FLOAT-DERIVE-TYPE-AUX ...)
+ These are now fixed, but (COERCE HUGE 'SINGLE-FLOAT) still signals a
+ type-error at runtime. The question is, should it instead signal a
+ floating-point overflow, or return an infinity?
+
408: SUBTYPEP confusion re. OR of SATISFIES of not-yet-defined predicate
As reported by Levente M\'{e}sz\'{a}ros sbcl-devel 2006-02-20,
(aver (equal (multiple-value-list
behaves ...erratically. Reported by Kevin Reid on sbcl-devel
2007-07-06. (We don't _have_ to check things like this, but we
generally try to check returns in safe code, so we should here too.)
+
+423: TRULY-THE and *CHECK-CONSISTENCY*
+
+ The following signals errors due to TRULY-THEs in dead code:
+
+ (let ((sb-c::*check-consistency* t))
+ (handler-bind ((warning #'error))
+ (flet ((make-lambda (type)
+ `(lambda (x)
+ ((lambda (z)
+ (if (listp z)
+ (let ((q (truly-the list z)))
+ (length q))
+ (if (arrayp z)
+ (let ((q (truly-the vector z)))
+ (length q))
+ (error "oops"))))
+ (the ,type x)))))
+ (compile nil (make-lambda 'list))
+ (compile nil (make-lambda 'vector)))))