around the same time regarding a call to LIST on sparc with 1000
arguments) and other implementation limit constants.
-311: "Tokeniser not thread-safe"
- (see also Robert Marlow sbcl-help "Multi threaded read chucking a
- spak" 2004-04-19)
- The tokenizer's use of *read-buffer* and *read-buffer-length* causes
- spurious errors should two threads attempt to tokenise at the same
- time.
-
314: "LOOP :INITIALLY clauses and scope of initializers"
reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
test suite, originally by Thomas F. Burdick.
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").