your pre-0.7.0 state of grace with
#+sbcl (declaim (notinline find position find-if position-if)) ; bug 117..
+118:
+ as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14:
+ (= (FLOAT 1 DOUBLE-FLOAT-EPSILON)
+ (+ (FLOAT 1 DOUBLE-FLOAT-EPSILON) DOUBLE-FLOAT-EPSILON)) => T
+ when of course it should be NIL. (He says it only fails for X86,
+ not SPARC; dunno about Alpha.)
+
+ Also, "the same problem exists for LONG-FLOAT-EPSILON,
+ DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON (though
+ for the -negative- the + is replaced by a - in the test)."
+
+ Raymond Toy comments that this is tricky on the X86 since its FPU
+ uses 80-bit precision internally.
+
+119:
+ a bug in the byte compiler and/or interpreter: Compile
+ (IN-PACKAGE :CL-USER)
+ (DECLAIM (OPTIMIZE (SPEED 0) (SAFETY 1) (DEBUG 1)))
+ (DEFUN BAR (&REST DIMS)
+ (IF (EVERY #'INTEGERP DIMS)
+ 1
+ 2))
+ then execute (BAR '(1 2 3 4)). In sbcl-0.pre7.14.flaky4.8
+ this gives a TYPE-ERROR,
+ The value #:UNINITIALIZED-EVAL-STACK-ELEMENT is not
+ of type (MOD 536870911).
+ The same error will probably occur in earlier versions as well,
+ although the name of the uninitialized-element placeholder will
+ be shorter.
+
+ The same thing happens if the compiler macro expansion of
+ EVERY into MAP is hand-expanded:
+ (defun bar2 (dims)
+ (if (block blockname
+ (map nil
+ (lambda (dim)
+ (let ((pred-value (funcall #'integerp dim)))
+ (unless pred-value
+ (return-from blockname
+ nil))))
+ dims)
+ t)
+ 1
+ 2))
+ CMU CL doesn't have this compiler macro expansion, so it was
+ immune to the original bug in BAR, but once we hand-expand it
+ into BAR2, CMU CL 18c has the same bug. (Run (BAR '(NIL NIL)).)
+
+ The native compiler handles it fine, both in SBCL and in CMU CL.
+
+120a:
+ The compiler incorrectly figures the return type of
+ (DEFUN FOO (FRAME UP-FRAME)
+ (IF (OR (NOT FRAME)
+ T)
+ FRAME
+ "BAR"))
+ as NIL.
+
+ This problem exists in CMU CL 18c too. When I reported it on
+ cmucl-imp@cons.org, Raymond Toy replied 23 Aug 2001 with
+ a partial explanation, but no fix has been found yet.
+
+120b:
+ Even in sbcl-0.pre7.x, which is supposed to be free of the old
+ non-ANSI behavior of treating the function return type inferred
+ from the current function definition as a declaration of the
+ return type from any function of that name, the return type of NIL
+ is attached to FOO in 120a above, and used to optimize code which
+ calls FOO.
+
+121:
+ In sbcl-0.7.14.flaky4.10, the last MAPTEST test case at the end
+ of tests/map-tests.impure.lisp dies with
+ The value
+ #<SB-C::MV-COMBINATION
+ :FUN #<SB-C::REF
+ :LEAF #<SB-C::GLOBAL-VAR
+ :NAME +
+ :TYPE #
+ :WHERE-FROM :DECLARED
+ :KIND :GLOBAL-FUNCTION>>
+ :ARGS (#<SB-C::COMBINATION :FUN # :ARGS (#)>)>
+ is not of type
+ SB-C::COMBINATION.
+ in
+ (SB-C::GENERATE-BYTE-CODE-FOR-REF
+ #<SB-ASSEM:SEGMENT :NAME "Byte Output">
+ #<SB-C::REF
+ :LEAF #<SB-C::GLOBAL-VAR
+ :NAME +
+ :TYPE #<SB-KERNEL:FUNCTION-TYPE (FUNCTION # NUMBER)>
+ :WHERE-FROM :DECLARED
+ :KIND :GLOBAL-FUNCTION>>
+ #<SB-C::CONTINUATION {506AD995}>)
+
KNOWN BUGS RELATED TO THE IR1 INTERPRETER
(Note: At some point, the pure interpreter (actually a semi-pure
interpreter is gone, the system's notion of what's a top-level form
and what's not will remain too confused to fix this problem.]
-IR1-5:
- (not really a bug, just a wishlist thing which might be easy
- when EVAL-WHEN is rewritten..) It might be good for the cross-compiler
- to warn about nested EVAL-WHENs. (In ordinary compilation, they're
- quite likely to be OK, but in cross-compiled code EVAL-WHENs
- are a great source of confusion, so a style warning about anything
- unusual could be helpful.)
-
IR1-6:
(another wishlist thing..) Reimplement DEFMACRO to be basically
like DEFMACRO-MUNDANELY, just using EVAL-WHEN.
projects / sbcl.git / blobdiff