+117:
+ When the compiler inline expands functions, it may be that different
+ kinds of return values are generated from different code branches.
+ E.g. an inline expansion of POSITION generates integer results
+ from one branch, and NIL results from another. When that inline
+ expansion is used in a context where only one of those results
+ is acceptable, e.g.
+ (defun foo (x)
+ (aref *a1* (position x *a2*)))
+ and the compiler can't prove that the unacceptable branch is
+ never taken, then bogus type mismatch warnings can be generated.
+ If you need to suppress the type mismatch warnings, you can
+ suppress the inline expansion,
+ (defun foo (x)
+ #+sbcl (declare (notinline position)) ; to suppress bug 117 bogowarnings
+ (aref *a1* (position x *a2*)))
+ or, sometimes, suppress them by declaring the result to be of an
+ appropriate type,
+ (defun foo (x)
+ (aref *a1* (the integer (position x *a2*))))
+
+ This is not a new compiler problem in 0.7.0, but the new compiler
+ transforms for FIND, POSITION, FIND-IF, and POSITION-IF make it
+ more conspicuous. If you don't need performance from these functions,
+ and the bogus warnings are a nuisance for you, you can return to
+ 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.
+
+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.
+
+122:
+ There was some sort of screwup in handling of
+ (IF (NOT (IGNORE-ERRORS ..))). E.g.
+ (defun foo1i ()
+ (if (not (ignore-errors
+ (make-pathname :host "foo" :directory "!bla" :name "bar")))
+ (print "ok")
+ (error "notunlessnot")))
+ The (NOT (IGNORE-ERRORS ..)) form evaluates to T, so this should be
+ printing "ok", but instead it's going to the ERROR. This problem
+ seems to've been introduced by MNA's HANDLER-CASE patch (sbcl-devel
+ 2001-07-17) and as a workaround (put in sbcl-0.pre7.14.flaky4.12)
+ I reverted back to the old weird HANDLER-CASE code. However, I
+ think the problem looks like a compiler bug in handling RETURN-FROM,
+ so I left the MNA-patched code in HANDLER-CASE (suppressed with
+ #+NIL) and I'd like to go back to see whether this really is
+ a compiler bug before I delete this BUGS entry.
+
+123:
+ The *USE-IMPLEMENTATION-TYPES* hack causes bugs, particularly
+ (IN-PACKAGE :SB-KERNEL)
+ (TYPE= (SPECIFIER-TYPE '(VECTOR T))
+ (SPECIFIER-TYPE '(VECTOR UNDEFTYPE)))
+ Then because of this, the compiler bogusly optimizes
+ (TYPEP #(11) '(SIMPLE-ARRAY UNDEF-TYPE 1))
+ to T. Unfortunately, just setting *USE-IMPLEMENTATION-TYPES* to
+ NIL around sbcl-0.pre7.14.flaky4.12 didn't work: the compiler complained
+ about type mismatches (probably harmlessly, another instance of bug 117);
+ and then cold init died with a segmentation fault.
+
+124:
+ As of version 0.pre7.14, SBCL's implementation of MACROLET makes
+ the entire lexical environment at the point of MACROLET available
+ in the bodies of the macroexpander functions. In particular, it
+ allows the function bodies (which run at compile time) to try to
+ access lexical variables (which are only defined at runtime).
+ It doesn't even issue a warning, which is bad.
+
+ The SBCL behavior arguably conforms to the ANSI spec (since the
+ spec says that the behavior is undefined, ergo anything conforms).
+ However, it would be better to issue a compile-time error.
+ Unfortunately I (WHN) don't see any simple way to detect this
+ condition in order to issue such an error, so for the meantime
+ SBCL just does this weird broken "conforming" thing.
+
+ The ANSI standard says, in the definition of the special operator
+ MACROLET,
+ The macro-expansion functions defined by MACROLET are defined
+ in the lexical environment in which the MACROLET form appears.
+ Declarations and MACROLET and SYMBOL-MACROLET definitions affect
+ the local macro definitions in a MACROLET, but the consequences
+ are undefined if the local macro definitions reference any
+ local variable or function bindings that are visible in that
+ lexical environment.
+ Then it seems to contradict itself by giving the example
+ (defun foo (x flag)
+ (macrolet ((fudge (z)
+ ;The parameters x and flag are not accessible
+ ; at this point; a reference to flag would be to
+ ; the global variable of that name.
+ ` (if flag (* ,z ,z) ,z)))
+ ;The parameters x and flag are accessible here.
+ (+ x
+ (fudge x)
+ (fudge (+ x 1)))))
+ The comment "a reference to flag would be to the global variable
+ of the same name" sounds like good behavior for the system to have.
+ but actual specification quoted above says that the actual behavior
+ is undefined.
+
+125:
+ (as reported by Gabe Garza on cmucl-help 2001-09-21)
+ (defvar *tmp* 3)
+ (defun test-pred (x y)
+ (eq x y))
+ (defun test-case ()
+ (let* ((x *tmp*)
+ (func (lambda () x)))
+ (print (eq func func))
+ (print (test-pred func func))
+ (delete func (list func))))
+ Now calling (TEST-CASE) gives output
+ NIL
+ NIL
+ (#<FUNCTION {500A9EF9}>)
+ Evidently Python thinks of the lambda as a code transformation so
+ much that it forgets that it's also an object.
+
+126:
+ (fixed in 0.pre7.41)