(when (and (digs) (digs)) x))))
;;; Bug 132: The compiler used to fail to compile INTEGER-valued CATCH
-;;; tags. This was fixed by Alexey Dejneka in sbcl-0.7.1.14. (They're
-;;; still a bad idea because tags are compared with EQ, but now it's a
+;;; tags. This was fixed by Alexey Dejneka in sbcl-0.7.1.14. (INTEGER
+;;; catch tags are still a bad idea because EQ is used to compare
+;;; tags, and EQ comparison on INTEGERs is unportable; but now it's a
;;; compiler warning instead of a failure to compile.)
(defun foo ()
(catch 0 (print 1331)))
+
+;;; Bug 150: In sbcl-0.7.1.15, compiling this code caused a failure in
+;;; SB-C::ADD-TEST-CONSTRAINTS:
+;;; The value NIL is not of type SB-C::CONTINUATION.
+;;; This bug was fixed by APD in sbcl-0.7.1.30.
+(defun bug150-test1 ()
+ (let* ()
+ (flet ((wufn () (glorp table1 4.9)))
+ (gleep *uustk* #'wufn "#1" (list)))
+ (if (eql (lo foomax 3.2))
+ (values)
+ (error "not ~S" '(eql (lo foomax 3.2))))
+ (values)))
+;;; A simpler test case for bug 150: The compiler died with the
+;;; same type error when trying to compile this.
+(defun bug150-test2 ()
+ (let ()
+ (<)))
+
+;;; bug 147, fixed by APD 2002-04-28
+;;;
+;;; This test case used to crash the compiler, e.g. with
+;;; failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)"
+(defun bug147 (string ind)
+ (flet ((digs ()
+ (let (old-index)
+ (if (and (< ind ind)
+ (typep (char string ind) '(member #\1)))
+ nil))))))
+
+;;; bug reported and fixed by Matthias Hoelzl sbcl-devel 2002-05-13
+(defmacro foo-2002-05-13 () ''x)
+(eval '(foo-2002-05-13))
+(compile 'foo-2002-05-13)
+(foo-2002-05-13) ; (The bug caused UNDEFINED-FUNCTION to be signalled here.)
+
+;;; floating point pain on the PPC.
+;;;
+;;; This test case used to fail to compile on most powerpcs prior to
+;;; sbcl-0.7.4.2x, as floating point traps were being incorrectly
+;;; masked.
+(defun floating-point-pain (x)
+ (declare (single-float x))
+ (log x))
+
+;;; bug found and fixed ca. sbcl-0.7.5.12: The INTERSECTION-TYPE
+;;; here satisfies "is a subtype of ARRAY-TYPE", but can't be
+;;; accessed with ARRAY-TYPE accessors like
+;;; ARRAY-TYPE-SPECIALIZED-ELEMENT-TYPE, so ARRAY-related
+;;; DEFTRANSFORMs died with TYPE-ERROR at compile time when
+;;; compiling the DEFUN here.
+(defun stupid-input-to-smart-array-deftransforms-0-7-5-12 (v)
+ (declare (type (and simple-vector fwd-type-ref) v))
+ (aref v 0))
+
+;;; Ca. sbcl-0.7.5.15 the compiler would fail an internal consistency
+;;; check on this code because it expected all calls to %INSTANCE-REF
+;;; to be transformed away, but its expectations were dashed by perverse
+;;; code containing app programmer errors like this.
+(defstruct something-known-to-be-a-struct x y)
+(multiple-value-bind (fun warnings-p failure-p)
+ (compile nil
+ '(lambda ()
+ (labels ((a1 (a2 a3)
+ (cond (t (a4 a2 a3))))
+ (a4 (a2 a3 a5 a6)
+ (declare (type (or simple-vector null) a5 a6))
+ (something-known-to-be-a-struct-x a5))
+ (a8 (a2 a3)
+ (a9 #'a1 a10 a2 a3))
+ (a11 (a2 a3)
+ (cond ((and (funcall a12 a2)
+ (funcall a12 a3))
+ (funcall a13 a2 a3))
+ (t
+ (when a14
+ (let ((a15 (a1 a2 a3)))
+ ))
+ a16))))
+ (values #'a17 #'a11))))
+ ;; Python sees the structure accessor on the known-not-to-be-a-struct
+ ;; A5 value and is very, very disappointed in you. (But it doesn't
+ ;; signal BUG any more.)
+ (assert failure-p))
+
+;;; On the SPARC, there was an erroneous definition of some VOPs used
+;;; to compile LOGANDs, which would lead to compilation of the
+;;; following function giving rise to a compile-time error (bug
+;;; spotted and fixed by Raymond Toy for CMUCL)
+(defun logand-sparc-bogons (a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10)
+ (declare (type (unsigned-byte 32) a0)
+ (type (signed-byte 32) a1 a2 a3 a4 a5 a6 a7 a8 a9 a10)
+ ;; to ensure that the call is a candidate for
+ ;; transformation
+ (optimize (speed 3) (safety 0) (compilation-speed 0) (debug 0)))
+ (values
+ ;; the call that fails compilation
+ (logand a0 a10)
+ ;; a call to prevent the other arguments from being optimized away
+ (logand a1 a2 a3 a4 a5 a6 a7 a8 a9)))
\f
;;;; tests not in the problem domain, but of the consistency of the
;;;; compiler machinery itself