+
+368: miscompiled OR (perhaps related to bug 367)
+ Trying to relax type declarations to find a workaround for bug 367,
+ it turns out that even when the return type isn't declared (or
+ declared to be T, anyway) the system remains confused about type
+ inference in code similar to that for bug 367:
+ (in-package :cl-user)
+ (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1)))
+ (defstruct e368)
+ (defstruct i368)
+ (defstruct g368
+ (i368s (make-array 0 :fill-pointer t) :type (or (vector i368) null)))
+ (defstruct s368
+ (g368 (error "missing :G368") :type g368 :read-only t))
+ (declaim (ftype (function (fixnum (vector i368) e368) t) r368))
+ (declaim (ftype (function (fixnum (vector e368)) t) h368))
+ (defparameter *h368-was-called-p* nil)
+ (defun nsu (vertices e368)
+ (let ((i368s (g368-i368s (make-g368))))
+ (let ((fuis (r368 0 i368s e368)))
+ (format t "~&FUIS=~S~%" fuis)
+ (or fuis (h368 0 i368s)))))
+ (defun r368 (w x y)
+ (declare (ignore w x y))
+ nil)
+ (defun h368 (w x)
+ (declare (ignore w x))
+ (setf *h368-was-called-p* t)
+ (make-s368 :g368 (make-g368)))
+ (trace r368 h368)
+ (format t "~&calling NSU~%")
+ (let ((nsu (nsu #() (make-e368))))
+ (format t "~&NSU returned ~S~%" nsu)
+ (format t "~&*H368-WAS-CALLED-P*=~S~%" *h368-was-called-p*)
+ (assert (s368-p nsu))
+ (assert *h368-was-called-p*))
+ In sbcl-0.8.18, both ASSERTs fail, and (DISASSEMBLE 'NSU) shows
+ that no call to H368 is compiled.
+
+369: unlike-an-intersection behavior of VALUES-TYPE-INTERSECTION
+ In sbcl-0.8.18.2, the identity $(x \cap y \cap y)=(x \cap y)$
+ does not hold for VALUES-TYPE-INTERSECTION, even for types which
+ can be intersected exactly, so that ASSERTs fail in this test case:
+ (in-package :cl-user)
+ (let ((types (mapcar #'sb-c::values-specifier-type
+ '((values (vector package) &optional)
+ (values (vector package) &rest t)
+ (values (vector hash-table) &rest t)
+ (values (vector hash-table) &optional)
+ (values t &optional)
+ (values t &rest t)
+ (values nil &optional)
+ (values nil &rest t)
+ (values sequence &optional)
+ (values sequence &rest t)
+ (values list &optional)
+ (values list &rest t)))))
+ (dolist (x types)
+ (dolist (y types)
+ (let ((i (sb-c::values-type-intersection x y)))
+ (assert (sb-c::type= i (sb-c::values-type-intersection i x)))
+ (assert (sb-c::type= i (sb-c::values-type-intersection i y)))))))
+
+370: reader misbehaviour on large-exponent floats
+ (read-from-string "1.0s1000000000000000000000000000000000000000")
+ causes the reader to attempt to create a very large bignum (which it
+ will then attempt to coerce to a rational). While this isn't
+ completely wrong, it is probably not ideal -- checking the floating
+ point control word state and then returning the relevant float
+ (most-positive-short-float or short-float-infinity) or signalling an
+ error immediately would seem to make more sense.
+
+372: floating-point overflow not signalled on ppc/darwin
+ The following assertions in float.pure.lisp fail on ppc/darwin
+ (Mac OS X version 10.3.7):
+ (assert (raises-error? (scale-float 1.0 most-positive-fixnum)
+ floating-point-overflow))
+ (assert (raises-error? (scale-float 1.0d0 (1+ most-positive-fixnum))
+ floating-point-overflow)))
+ as the SCALE-FLOAT just returns
+ #.SB-EXT:SINGLE/DOUBLE-FLOAT-POSITIVE-INFINITY. These tests have been
+ disabled on Darwin for now.
+
+375: MISC.555
+ (compile nil '(lambda (p1)
+ (declare (optimize (speed 1) (safety 2) (debug 2) (space 0))
+ (type keyword p1))
+ (keywordp p1)))
+
+ fails on hairy type check in IR2.
+
+ 1. KEYWORDP is MAYBE-INLINE expanded (before TYPEP-like
+ transformation could eliminate it).
+
+ 2. From the only call of KEYWORDP the type of its argument is
+ derived to be KEYWORD.
+
+ 2. Type check for P1 is generated; it uses KEYWORDP to perform the
+ check, and so references the local function; from the KEYWORDP
+ argument type new CAST to KEYWORD is generated. The compiler
+ loops forever.
+
+377: Memory fault error reporting
+ On those architectures where :C-STACK-IS-CONTROL-STACK is in
+ *FEATURES*, we handle SIG_MEMORY_FAULT (SEGV or BUS) on an altstack,
+ so we cannot handle the signal directly (as in interrupt_handle_now())
+ in the case when the signal comes from some external agent (the user
+ using kill(1), or a fault in some foreign code, for instance). As
+ of sbcl-0.8.20.20, this is fixed by calling
+ arrange_return_to_lisp_function() to a new error-signalling
+ function, but as a result the error reporting is poor: we cannot
+ even tell the user at which address the fault occurred. We should
+ arrange such that arguments can be passed to the function called from
+ arrange_return_to_lisp_function(), but this looked hard to do in
+ general without suffering from memory leaks.
+
+379: TRACE :ENCAPSULATE NIL broken on ppc/darwin
+ See commented-out test-case in debug.impure.lisp.
+
+380: Accessor redefinition fails because of old accessor name
+ When redefining an accessor, SB-PCL::FIX-SLOT-ACCESSORS may try to
+ find the generic function named by the old accessor name using
+ ENSURE-GENERIC-FUNCTION and then remove the old accessor's method in
+ the GF. If the old name does not name a function, or if the old name
+ does not name a generic function, no attempt to find the GF or remove
+ any methods is made.
+
+ However, if an unrelated GF with an incompatible lambda list exists,
+ the class redefinition will fail when SB-PCL::REMOVE-READER-METHOD
+ tries to find and remove a method with an incompatible lambda list
+ from the unrelated generic function.
+
+381: incautious calls to EQUAL in fasl dumping
+ Compiling
+ (frob #(#1=(a #1#)))
+ (frob #(#1=(b #1#)))
+ (frob #(#1=(a #1#)))
+ in sbcl-0.9.0 causes CONTROL-STACK-EXHAUSTED. My (WHN) impression
+ is that this follows from the use of (MAKE-HASH-TABLE :TEST 'EQUAL)
+ to detect sharing, in which case fixing it might require either
+ getting less ambitious about detecting shared list structure, or
+ implementing the moral equivalent of EQUAL hash tables in a
+ cycle-tolerant way.
+
+382: externalization unexpectedly changes array simplicity
+ COMPILE-FILE and LOAD
+ (defun foo ()
+ (let ((x #.(make-array 4 :fill-pointer 0)))
+ (values (eval `(typep ',x 'simple-array))
+ (typep x 'simple-array))))
+ then (FOO) => T, NIL.
+
+ Similar problems exist with SIMPLE-ARRAY-P, ARRAY-HEADER accessors
+ and all array dimension functions.
+
+383: ASH'ing non-constant zeros
+ Compiling
+ (lambda (b)
+ (declare (type (integer -2 14) b))
+ (declare (ignorable b))
+ (ash (imagpart b) 57))
+ on PPC (and other platforms, presumably) gives an error during the
+ emission of FASH-ASH-LEFT/FIXNUM=>FIXNUM as the assembler attempts to
+ stuff a too-large constant into the immediate field of a PPC
+ instruction. Either the VOP should be fixed or the compiler should be
+ taught how to transform this case away, paying particular attention
+ to side-effects that might occur in the arguments to ASH.
+
+384: Compiler runaway on very large character types
+
+ (compile nil '(lambda (x)
+ (declare (type (member #\a 1) x))
+ (the (member 1 nil) x)))
+
+ The types apparently normalize into a very large type, and the compiler
+ gets lost in REMOVE-DUPLICATES. Perhaps the latter should use
+ a better algorithm (one based on hash tables, say) on very long lists
+ when :TEST has its default value?
+
+ A simpler example:
+
+ (compile nil '(lambda (x) (the (not (eql #\a)) x)))
+
+ (partially fixed in 0.9.3.1, but a better representation for these
+ types is needed.)
+
+385:
+ (format nil "~4,1F" 0.001) => "0.00" (should be " 0.0");
+ (format nil "~4,1@F" 0.001) => "+.00" (should be "+0.0").
+
+386: SunOS/x86 stack exhaustion handling broken
+ According to <http://alfa.s145.xrea.com/sbcl/solaris-x86.html>, the
+ stack exhaustion checking (implemented with a write-protected guard
+ page) does not work on SunOS/x86.
+
+387:
+ 12:10 < jsnell> the package-lock test is basically due to a change in the test
+ behaviour when you install a handler for error around it. I
+ thought I'd disabled the test for now, but apparently that was
+ my imagination
+ 12:19 < Xophe> jsnell: ah, I see the problem in the package-locks stuff
+ 12:19 < Xophe> it's the same problem as we had with compiler-error conditions
+ 12:19 < Xophe> the thing that's signalled up and down the stack is a subtype of
+ ERROR, where it probably shouldn't be
+
+388:
+ (found by Dmitry Bogomolov)
+
+ (defclass foo () ((x :type (unsigned-byte 8))))
+ (defclass bar () ((x :type symbol)))
+ (defclass baz (foo bar) ())
+
+ causes error
+
+ SB-PCL::SPECIALIZER-APPLICABLE-USING-TYPE-P cannot handle the second argument
+ (UNSIGNED-BYTE 8).
+
+389:
+ (reported several times on sbcl-devel, by Rick Taube, Brian Rowe and
+ others)
+
+ ROUND-NUMERIC-BOUND assumes that float types always have a FORMAT
+ specifying whether they're SINGLE or DOUBLE. This is true for types
+ computed by the type system itself, but the compiler type derivation
+ short-circuits this and constructs non-canonical types. A temporary
+ fix was made to ROUND-NUMERIC-BOUND for the sbcl-0.9.6 release, but
+ the right fix is to remove the abstraction violation in the
+ compiler's type deriver.
+
+392: slot-accessor for subclass misses obsoleted superclass
+ (fixed in sbcl-0.9.7.9)
+
+393: Wrong error from methodless generic function
+ (DEFGENERIC FOO (X))
+ (FOO 1 2)
+ gives NO-APPLICABLE-METHOD rather than an argument count error.
+
+394: (SETF CLASS-NAME)/REINITIALIZE-INSTANCE bug
+ (found by PFD ansi-tests)
+ in sbcl-0.9.7.15, (SETF (CLASS-NAME <class>) 'NIL) causes
+ (FIND-CLASS NIL) to return a #<STANDARD-CLASS NIL>.