+
+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.
+
+413: type-errors in ROOM
+
+ (defvar *a* (make-array (expt 2 27)))
+ (room)
+
+ Causes a type-error on 32bit SBCL, as various byte-counts in ROOM
+ implementation overrun fixnums.
+
+ This was fixed in 1.0.4.89, but the patch was reverted as it caused
+ ROOM to cons sufficiently to make running it in a loop deadly on
+ GENCGC: newly allocated objects survived to generation 1, where next
+ call to ROOM would see them, and allocate even more...
+
+ Reported by Faré Rideau on sbcl-devel.
+
+414: strange DISASSEMBLE warning
+
+ Compiling and disassembling
+
+ (defun disassemble-source-form-bug (x y z)
+ (declare (optimize debug))
+ (list x y z))
+
+ Gives
+
+ WARNING: bogus form-number in form! The source file has probably
+ been changed too much to cope with.
+
+415: Issues creating large arrays on x86-64/Linux and x86/Darwin
+
+ (make-array (1- array-dimension-limit))
+
+ causes a GC invariant violation on x86-64/Linux, and
+ an unhandled SIGILL on x86/Darwin.
+
+416: backtrace confusion
+
+ (defun foo (x)
+ (let ((v "foo"))
+ (flet ((bar (z)
+ (oops v z)
+ (oops z v)))
+ (bar x)
+ (bar v))))
+ (foo 13)
+
+ gives the correct error, but the backtrace shows
+ 1: (SB-KERNEL:FDEFINITION-OBJECT 13 NIL)
+ as the second frame.
+
+418: SUBSEQ on lists doesn't support bignum indexes
+
+ LIST-SUBSEQ* now has all the works necessary to support bignum indexes,
+ but it needs to be verified that changing the DEFKNOWN doesn't kill
+ performance elsewhere.
+
+ Other generic sequence functions have this problem as well.
+
+419: stack-allocated indirect closure variables are not popped
+
+ (locally (declare (optimize speed (safety 0)))
+ (defun bug419 (x)
+ (multiple-value-call #'list
+ (eval '(values 1 2 3))
+ (let ((x x))
+ (declare (dynamic-extent x))
+ (flet ((mget (y)
+ (+ x y))
+ (mset (z)
+ (incf x z)))
+ (declare (dynamic-extent #'mget #'mset))
+ ((lambda (f g) (eval `(progn ,f ,g (values 4 5 6)))) #'mget #'mset))))))
+
+ (ASSERT (EQUAL (BUG419) '(1 2 3 4 5 6))) => failure
+
+420: The MISC.556 test from gcl/ansi-tests/misc.lsp fails hard.
+
+In sbcl-1.0.13 on Linux/x86, executing
+ (FUNCALL
+ (COMPILE NIL
+ '(LAMBDA (P1 P2)
+ (DECLARE
+ (OPTIMIZE (SPEED 1) (SAFETY 0) (DEBUG 0) (SPACE 0))
+ (TYPE (MEMBER 8174.8604) P1) (TYPE (MEMBER -95195347) P2))
+ (FLOOR P1 P2)))
+ 8174.8604 -95195347)
+interactively causes
+ SB-SYS:MEMORY-FAULT-ERROR: Unhandled memory fault at #x8.
+The gcl/ansi-tests/doit.lisp program terminates prematurely shortly after
+MISC.556 by falling into gdb with
+ fatal error encountered in SBCL pid 2827: Unhandled SIGILL
+unless the MISC.556 test is commented out.
+
+Analysis: + and a number of other arithmetic functions exhibit the
+same behaviour. Here's the underlying problem: On x86 we perform
+single-float + integer normally using double-precision, and then
+coerce the result back to single-float. (The FILD instruction always
+gives us a double-float, and unless we do MOVE-FROM-SINGLE it remains
+one. Or so it seems to me, and that would also explain the observed
+behaviour below.)
+
+During IR1 we derive the types for both
+
+ (+ <single> <integer>) ; uses double-precision
+ (+ <single> (FLOAT <integer> <single>)) ; uses single-precision
+
+and get a mismatch for a number of unlucky arguments. This leads to
+derived result type NIL, and ends up flushing the whole whole
+operation -- and finally we generate code without a return sequence,
+and fall through to whatever.
+
+The use of double-precision in the first case appears to be an
+(un)happy accident -- interval arithmetic gives us the
+double-precision result because that's what the backend does.
+
+ (+ 8172.0 (coerce -95195347 'single-float)) ; => -9.518717e7
+ (+ 8172.0 -95195347) ; => -9.5187176e7
+ (coerce (+ 8172.0 (coerce -95195347 'double-float)) 'single-float)
+ ; => -9.5187176e7
+
+Which should be fixed, the IR1, or the backend?
+
+421: READ-CHAR-NO-HANG misbehaviour on Windows Console:
+
+ It seems that on Windows READ-CHAR-NO-HANG hangs if the user
+ has pressed a key, but not yet enter (ie. SYSREAD-MAY-BLOCK-P
+ seems to lie if the OS is buffering input for us on Console.)
+
+ reported by Elliot Slaughter on sbcl-devel 2008/1/10.