+402: "DECLAIM DECLARATION does not inform the PCL code-walker"
+ reported by Vincent Arkesteijn:
+
+ (declaim (declaration foo))
+ (defgeneric bar (x))
+ (defmethod bar (x)
+ (declare (foo x))
+ x)
+
+ ==> WARNING: The declaration FOO is not understood by
+ SB-PCL::SPLIT-DECLARATIONS.
+ Please put FOO on one of the lists SB-PCL::*NON-VAR-DECLARATIONS*,
+ SB-PCL::*VAR-DECLARATIONS-WITH-ARG*, or
+ SB-PCL::*VAR-DECLARATIONS-WITHOUT-ARG*.
+ (Assuming it is a variable declaration without argument).
+
+403: FORMAT/PPRINT-LOGICAL-BLOCK of CONDITIONs ignoring *PRINT-CIRCLE*
+ In sbcl-0.9.13.34,
+ (defparameter *c*
+ (make-condition 'simple-error
+ :format-control "ow... ~S"
+ :format-arguments '(#1=(#1#))))
+ (setf *print-circle* t *print-level* 4)
+ (format nil "~@<~A~:@>" *c*)
+ gives
+ "ow... (((#)))"
+ where I (WHN) believe the correct result is "ow... #1=(#1#)",
+ like the result from (PRINC-TO-STRING *C*). The question of
+ what the correct result is is complicated by the hairy text in
+ the Hyperspec "22.3.5.2 Tilde Less-Than-Sign: Logical Block",
+ Other than the difference in its argument, ~@<...~:> is
+ exactly the same as ~<...~:> except that circularity detection
+ is not applied if ~@<...~:> is encountered at top level in a
+ format string.
+ But because the odd behavior happens even without the at-sign,
+ (format nil "~<~A~:@>" (list *c*)) ; => "ow... (((#)))"
+ and because something seemingly similar can happen even in
+ PPRINT-LOGICAL-BLOCK invoked directly without FORMAT,
+ (pprint-logical-block (*standard-output* '(some nonempty list))
+ (format *standard-output* "~A" '#1=(#1#)))
+ (which prints "(((#)))" to *STANDARD-OUTPUT*), I don't think
+ that the 22.3.5.2 trickiness is fundamental to the problem.
+
+ My guess is that the problem is related to the logic around the MODE
+ argument to CHECK-FOR-CIRCULARITY, but I haven't reverse-engineered
+ enough of the intended meaning of the different MODE values to be
+ confident of this.
+
+404: nonstandard DWIMness in LOOP with unportably-ordered clauses
+ In sbcl-0.9.13, the code
+ (loop with stack = (make-array 2 :fill-pointer 2 :initial-element t)
+ for length = (length stack)
+ while (plusp length)
+ for element = (vector-pop stack)
+ collect element)
+ compiles without error or warning and returns (T T). Unfortunately,
+ it is inconsistent with the ANSI definition of the LOOP macro,
+ because it mixes up VARIABLE-CLAUSEs with MAIN-CLAUSEs. Furthermore,
+ SBCL's interpretation of the intended meaning is only one possible,
+ unportable interpretation of the noncompliant code; in CLISP 2.33.2,
+ the code compiles with a warning
+ LOOP: FOR clauses should occur before the loop's main body
+ and then fails at runtime with
+ VECTOR-POP: #() has length zero
+ perhaps because CLISP has shuffled the clauses into an
+ ANSI-compliant order before proceeding.
+
+405: a TYPE-ERROR in MERGE-LETS exercised at DEBUG 3
+ In sbcl-0.9.16.21 on linux/86, compiling
+ (declaim (optimize (debug 3)))
+ (defstruct foo bar)
+ (let ()
+ (flet ((i (x) (frob x (foo-bar foo))))
+ (i :five)))
+ causes a TYPE-ERROR
+ The value NIL is not of type SB-C::PHYSENV.
+ in MERGE-LETS.
+
+406: functional has external references -- failed aver
+ Given the following food in a single file
+ (eval-when (:compile-toplevel :load-toplevel :execute)
+ (defstruct foo3))
+ (defstruct bar
+ (foo #.(make-foo3)))
+ as of 0.9.18.11 the file compiler breaks on it:
+ failed AVER: "(NOT (FUNCTIONAL-HAS-EXTERNAL-REFERENCES-P CLAMBDA))"
+ Defining the missing MAKE-LOAD-FORM method makes the error go away.
+
+407: misoptimization of loop, COERCE 'FLOAT, and HANDLER-CASE for bignums
+ (reported by Ariel Badichi on sbcl-devel 2007-01-09)
+ 407a: In sbcl-1.0.1 on Linux x86,
+ (defun foo ()
+ (loop for n from (expt 2 1024) do
+ (handler-case
+ (coerce n 'single-float)
+ (simple-type-error ()
+ (format t "Got here.~%")
+ (return-from foo)))))
+ (foo)
+ causes an infinite loop, where handling the error would be expected.
+ 407b: In sbcl-1.0.1 on Linux x86,
+ (defun bar ()
+ (loop for n from (expt 2 1024) do
+ (handler-case
+ (format t "~E~%" (coerce n 'single-float))
+ (simple-type-error ()
+ (format t "Got here.~%")
+ (return-from bar)))))
+ fails to compile, with
+ Too large to be represented as a SINGLE-FLOAT: ...
+ from
+ 0: ((LABELS SB-BIGNUM::CHECK-EXPONENT) ...)
+ 1: ((LABELS SB-BIGNUM::FLOAT-FROM-BITS) ...)
+ 2: (SB-KERNEL:%SINGLE-FLOAT ...)
+ 3: (SB-C::BOUND-FUNC ...)
+ 4: (SB-C::%SINGLE-FLOAT-DERIVE-TYPE-AUX ...)
+
+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
+ (subtypep '(or (satisfies x) string)
+ '(or (satisfies x) integer)))
+ '(nil nil)))
+ fails. Also, beneath that failure lurks another failure,
+ (aver (equal (multiple-value-list
+ (subtypep 'string
+ '(or (satisfies x) integer)))
+ '(nil nil)))
+ Having looked at this for an hour or so in sbcl-1.0.2, and
+ specifically having looked at the output from
+ laptop$ sbcl
+ * (let ((x 'string)
+ (y '(or (satisfies x) integer)))
+ (trace sb-kernel::union-complex-subtypep-arg2
+ sb-kernel::invoke-complex-subtypep-arg1-method
+ sb-kernel::type-union
+ sb-kernel::type-intersection
+ sb-kernel::type=)
+ (subtypep x y))
+ my (WHN) impression is that the problem is that the semantics of TYPE=
+ are wrong for what the UNION-COMPLEX-SUBTYPEP-ARG2 code is trying
+ to use it for. The comments on the definition of TYPE= probably
+ date back to CMU CL and seem to define it as a confusing thing:
+ its primary value is something like "certainly equal," and its
+ secondary value is something like "certain about that certainty."
+ I'm left uncertain how to fix UNION-COMPLEX-SUBTYPEP-ARG2 without
+ reducing its generality by removing the TYPE= cleverness. Possibly
+ the tempting TYPE/= relative defined next to it might be a
+ suitable replacement for the purpose. Probably, though, it would
+ be best to start by reverse engineering exactly what TYPE= and
+ TYPE/= do, and writing an explanation which is so clear that one
+ can see immediately what it's supposed to mean in odd cases like
+ (TYPE= '(SATISFIES X) 'INTEGER) when X isn't defined yet.
+
+409: MORE TYPE SYSTEM PROBLEMS
+ Found while investigating an optimization failure for extended
+ sequences. The extended sequence type implementation was altered to
+ work around the problem, but the fundamental problem remains, to wit:
+ (sb-kernel:type= (sb-kernel:specifier-type '(or float ratio))
+ (sb-kernel:specifier-type 'single-float))
+ returns NIL, NIL on sbcl-1.0.3.
+ (probably related to bug #408)
+
+410: read circularities and type declarations
+ Consider the definition
+ (defstruct foo (a 0 :type (not symbol)))
+ followed by
+ (setf *print-circle* t) ; just in case
+ (read-from-string "#1=#s(foo :a #1#)")
+ This gives a type error (#:G1 is not a (NOT SYMBOL)) because of the
+ implementation of read circularity, using a symbol as a marker for
+ the previously-referenced object.
+
+411: NAN issues on x86-64
+ Test :NAN-COMPARISONS in float.pure.lisp fails on x86-64, and has been
+ disabled on those platforms. Since x86 does not exhibit any problems
+ the problem is probably with the new FP implementation.