+
+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.
+
+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.
+
+
+
+