+
+62:
+ The compiler is supposed to do type inference well enough that
+ the declaration in
+ (TYPECASE X
+ ((SIMPLE-ARRAY SINGLE-FLOAT)
+ (LOCALLY
+ (DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT) X))
+ ..))
+ ..)
+ is redundant. However, as reported by Juan Jose Garcia Ripoll for
+ CMU CL, it sometimes doesn't. Adding declarations is a pretty good
+ workaround for the problem for now, but can't be done by the TYPECASE
+ macros themselves, since it's too hard for the macro to detect
+ assignments to the variable within the clause.
+ Note: The compiler *is* smart enough to do the type inference in
+ many cases. This case, derived from a couple of MACROEXPAND-1
+ calls on Ripoll's original test case,
+ (DEFUN NEGMAT (A)
+ (DECLARE (OPTIMIZE SPEED (SAFETY 0)))
+ (COND ((TYPEP A '(SIMPLE-ARRAY SINGLE-FLOAT)) NIL
+ (LET ((LENGTH (ARRAY-TOTAL-SIZE A)))
+ (LET ((I 0) (G2554 LENGTH))
+ (DECLARE (TYPE REAL G2554) (TYPE REAL I))
+ (TAGBODY
+ SB-LOOP::NEXT-LOOP
+ (WHEN (>= I G2554) (GO SB-LOOP::END-LOOP))
+ (SETF (ROW-MAJOR-AREF A I) (- (ROW-MAJOR-AREF A I)))
+ (GO SB-LOOP::NEXT-LOOP)
+ SB-LOOP::END-LOOP))))))
+ demonstrates the problem; but the problem goes away if the TAGBODY
+ and GO forms are removed (leaving the SETF in ordinary, non-looping
+ code), or if the TAGBODY and GO forms are retained, but the
+ assigned value becomes 0.0 instead of (- (ROW-MAJOR-AREF A I)).
+
+63:
+ Paul Werkowski wrote on cmucl-imp@cons.org 2000-11-15
+ I am looking into this problem that showed up on the cmucl-help
+ list. It seems to me that the "implementation specific environment
+ hacking functions" found in pcl/walker.lisp are completely messed
+ up. The good thing is that they appear to be barely used within
+ PCL and the munged environment object is passed to cmucl only
+ in calls to macroexpand-1, which is probably why this case fails.
+ SBCL uses essentially the same code, so if the environment hacking
+ is screwed up, it affects us too.
+
+64:
+ Using the pretty-printer from the command prompt gives funny
+ results, apparently because the pretty-printer doesn't know
+ about user's command input, including the user's carriage return
+ that the user, and therefore the pretty-printer thinks that
+ the new output block should start indented 2 or more characters
+ rightward of the correct location.
+
+65:
+ (probably related to bug #70)
+ As reported by Carl Witty on submit@bugs.debian.org 1999-05-08,
+ compiling this file
+(in-package "CL-USER")
+(defun equal-terms (termx termy)
+ (labels
+ ((alpha-equal-bound-term-lists (listx listy)
+ (or (and (null listx) (null listy))
+ (and listx listy
+ (let ((bindings-x (bindings-of-bound-term (car listx)))
+ (bindings-y (bindings-of-bound-term (car listy))))
+ (if (and (null bindings-x) (null bindings-y))
+ (alpha-equal-terms (term-of-bound-term (car listx))
+ (term-of-bound-term (car listy)))
+ (and (= (length bindings-x) (length bindings-y))
+ (prog2
+ (enter-binding-pairs (bindings-of-bound-term (car listx))
+ (bindings-of-bound-term (car listy)))
+ (alpha-equal-terms (term-of-bound-term (car listx))
+ (term-of-bound-term (car listy)))
+ (exit-binding-pairs (bindings-of-bound-term (car listx))
+ (bindings-of-bound-term (car listy)))))))
+ (alpha-equal-bound-term-lists (cdr listx) (cdr listy)))))
+
+ (alpha-equal-terms (termx termy)
+ (if (and (variable-p termx)
+ (variable-p termy))
+ (equal-bindings (id-of-variable-term termx)
+ (id-of-variable-term termy))
+ (and (equal-operators-p (operator-of-term termx) (operator-of-term termy))
+ (alpha-equal-bound-term-lists (bound-terms-of-term termx)
+ (bound-terms-of-term termy))))))
+
+ (or (eq termx termy)
+ (and termx termy
+ (with-variable-invocation (alpha-equal-terms termx termy))))))
+ causes an assertion failure
+ The assertion (EQ (C::LAMBDA-TAIL-SET C::CALLER)
+ (C::LAMBDA-TAIL-SET (C::LAMBDA-HOME C::CALLEE))) failed.
+
+ Bob Rogers reports (1999-07-28 on cmucl-imp@cons.org) a smaller test
+ case with the same problem:
+(defun parse-fssp-alignment ()
+ ;; Given an FSSP alignment file named by the argument . . .
+ (labels ((get-fssp-char ()
+ (get-fssp-char))
+ (read-fssp-char ()
+ (get-fssp-char)))
+ ;; Stub body, enough to tickle the bug.
+ (list (read-fssp-char)
+ (read-fssp-char))))
+
+66:
+ ANSI specifies that the RESULT-TYPE argument of CONCATENATE must be
+ a subtype of SEQUENCE, but CONCATENATE doesn't check this properly:
+ (CONCATENATE 'SIMPLE-ARRAY #(1 2) '(3)) => #(1 2 3)
+ This also leads to funny behavior when derived type specifiers
+ are used, as originally reported by Milan Zamazal for CMU CL (on the
+ Debian bugs mailing list (?) 2000-02-27), then reported by Martin
+ Atzmueller for SBCL (2000-10-01 on sbcl-devel@lists.sourceforge.net):
+ (DEFTYPE FOO () 'SIMPLE-ARRAY)
+ (CONCATENATE 'FOO #(1 2) '(3))
+ => #<ARRAY-TYPE SIMPLE-ARRAY> is a bad type specifier for
+ sequence functions.
+ The derived type specifier FOO should act the same way as the
+ built-in type SIMPLE-ARRAY here, but it doesn't. That problem
+ doesn't seem to exist for sequence types:
+ (DEFTYPE BAR () 'SIMPLE-VECTOR)
+ (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3)
+
+67:
+ As reported by Winton Davies on a CMU CL mailing list 2000-01-10,
+ and reported for SBCL by Martin Atzmueller 2000-10-20: (TRACE GETHASH)
+ crashes SBCL. In general tracing anything which is used in the
+ implementation of TRACE is likely to have the same problem.
+
+68:
+ As reported by Daniel Solaz on cmucl-help@cons.org 2000-11-23,
+ SXHASH returns the same value for all non-STRUCTURE-OBJECT instances,
+ notably including all PCL instances. There's a limit to how much
+ SXHASH can do to return unique values for instances, but at least
+ it should probably look at the class name, the way that it does
+ for STRUCTURE-OBJECTs.
+
+69:
+ As reported by Martin Atzmueller on the sbcl-devel list 2000-11-22,
+ > There remains one issue, that is a bug in SBCL:
+ > According to my interpretation of the spec, the ":" and "@" modifiers
+ > should appear _after_ the comma-seperated arguments.
+ > Well, SBCL (and CMUCL for that matter) accept
+ > (ASSERT (STRING= (FORMAT NIL "~:8D" 1) " 1"))
+ > where the correct way (IMHO) should be
+ > (ASSERT (STRING= (FORMAT NIL "~8:D" 1) " 1"))
+ Probably SBCL should stop accepting the "~:8D"-style format arguments,
+ or at least issue a warning.
+
+70:
+ (probably related to bug #65)
+ The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
+ forms. E.g.
+ (DEFUN FIND-BEFORE (ITEM SEQUENCE &KEY (TEST #'EQL))
+ (LABELS ((FIND-ITEM (OBJ SEQ TEST &OPTIONAL (VAL NIL))
+ (LET ((ITEM (FIRST SEQ)))
+ (COND ((NULL SEQ)
+ (VALUES NIL NIL))
+ ((FUNCALL TEST OBJ ITEM)
+ (VALUES VAL SEQ))
+ (T
+ (FIND-ITEM OBJ (REST SEQ) TEST (NCONC VAL `(,ITEM))))))))
+ (FIND-ITEM ITEM SEQUENCE TEST)))
+ from David Young's bug report on cmucl-help@cons.org 30 Nov 2000
+ causes sbcl-0.6.9 to fail with
+ error in function SB-KERNEL:ASSERT-ERROR:
+ The assertion (EQ (SB-C::LAMBDA-TAIL-SET SB-C::CALLER)
+ (SB-C::LAMBDA-TAIL-SET
+ (SB-C::LAMBDA-HOME SB-C::CALLEE))) failed.
+
+71:
+ (DECLAIM (OPTIMIZE ..)) doesn't work. E.g. even after
+ (DECLAIM (OPTIMIZE (SPEED 3))), things are still optimized with
+ the previous SPEED policy. This bug will probably get fixed in
+ 0.6.9.x in a general cleanup of optimization policy.
+
+72:
+ (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.
+
+74:
+ As noted in the ANSI specification for COERCE, (COERCE 3 'COMPLEX)
+ gives a result which isn't COMPLEX. The result type optimizer
+ for COERCE doesn't know this, perhaps because it was written before
+ ANSI threw this curveball: the optimizer thinks that COERCE always
+ returns a result of the specified type. Thus while the interpreted
+ function
+ (DEFUN TRICKY (X) (TYPEP (COERCE X 'COMPLEX) 'COMPLEX))
+ returns the correct result,
+ (TRICKY 3) => NIL
+ the compiled function
+ (COMPILE 'TRICKY)
+ does not:
+ (TRICKY 3) => T
+
+75:
+ As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000,
+ ANSI says that WITH-OUTPUT-TO-STRING should have a keyword
+ :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for
+ WITH-OUTPUT-TO-STRING.
+
+78:
+ ANSI says in one place that type declarations can be abbreviated even
+ when the type name is not a symbol, e.g.
+ (DECLAIM ((VECTOR T) *FOOVECTOR*))
+ SBCL doesn't support this. But ANSI says in another place that this
+ isn't allowed. So it's not clear this is a bug after all. (See the
+ e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN
+ and Pierre Mai.)
+
+79:
+ as pointed out by Dan Barlow on sbcl-devel 2000-07-02:
+ The PICK-TEMPORARY-FILE-NAME utility used by LOAD-FOREIGN uses
+ an easily guessable temporary filename in a way which might open
+ applications using LOAD-FOREIGN to hijacking by malicious users
+ on the same machine. Incantations for doing this safely are
+ floating around the net in various "how to write secure programs
+ despite Unix" documents, and it would be good to (1) fix this in
+ LOAD-FOREIGN, and (2) hunt for any other code which uses temporary
+ files and make it share the same new safe logic.
+
+80:
+ (fixed early Feb 2001 by MNA)
+
+81:
+ As reported by wbuss@TELDA.NET (Wolfhard Buss) on cmucl-help
+ 2001-02-14,
+ According to CLHS
+ (loop with (a . b) of-type float = '(0.0 . 1.0)
+ and (c . d) of-type float = '(2.0 . 3.0)
+ return (list a b c d))
+ should evaluate to (0.0 1.0 2.0 3.0). cmucl-18c disagrees and
+ invokes the debugger: "B is not of type list".
+ SBCL does the same thing.
+
+82:
+ Functions are assigned names based on the context in which they're
+ defined. This is less than ideal for the functions which are
+ used to implement CLOS methods. E.g. the output of
+ (DESCRIBE 'PRINT-OBJECT) lists functions like
+ #<FUNCTION "DEF!STRUCT (TRACE-INFO (:MAKE-LOAD-FORM-FUN SB-KERNEL:JUST-DUMP-IT-NORMALLY) (:PRINT-OBJECT #))" {1020E49}>
+ and
+ #<FUNCTION "MACROLET ((FORCE-DELAYED-DEF!METHODS NIL #))" {1242871}>
+ It would be better if these functions' names always identified
+ them as methods, and identified their generic functions and
+ specializers.
+
+83:
+ RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
+ RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
+ the mean of the distribution can be systematically O(0.1%) wrong.
+ Just increasing R-I-E-B is probably not a good solution, since
+ it would decrease efficiency more than is probably necessary. Perhaps
+ using some sort of accept/reject method would be better.
+
+KNOWN BUGS RELATED TO THE IR1 INTERPRETER
+
+(Note: At some point, the pure interpreter (actually a semi-pure
+interpreter aka "the IR1 interpreter") will probably go away, replaced
+by constructs like
+ (DEFUN EVAL (X) (FUNCALL (COMPILE NIL (LAMBDA ..)))))
+and at that time these bugs should either go away automatically or
+become more tractable to fix. Until then, they'll probably remain,
+since some of them aren't considered urgent, and the rest are too hard
+to fix as long as so many special cases remain. After the IR1
+interpreter goes away is also the preferred time to start
+systematically exterminating cases where debugging functionality
+(backtrace, breakpoint, etc.) breaks down, since getting rid of the
+IR1 interpreter will reduce the number of special cases we need to
+support.)
+
+IR1-1:
+ The FUNCTION special operator doesn't check properly whether its
+ argument is a function name. E.g. (FUNCTION (X Y)) returns a value
+ instead of failing with an error. (Later attempting to funcall the
+ value does cause an error.)
+
+IR1-2:
+ COMPILED-FUNCTION-P bogusly reports T for interpreted functions:
+ * (DEFUN FOO (X) (- 12 X))
+ FOO
+ * (COMPILED-FUNCTION-P #'FOO)
+ T
+
+IR1-3:
+ Executing
+ (DEFVAR *SUPPRESS-P* T)
+ (EVAL '(UNLESS *SUPPRESS-P*
+ (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
+ (FORMAT T "surprise!"))))
+ prints "surprise!". Probably the entire EVAL-WHEN mechanism ought to be
+ rewritten from scratch to conform to the ANSI definition, abandoning
+ the *ALREADY-EVALED-THIS* hack which is used in sbcl-0.6.8.9 (and
+ in the original CMU CL source, too). This should be easier to do --
+ though still nontrivial -- once the various IR1 interpreter special
+ cases are gone.
+
+IR1-3a:
+ EVAL-WHEN's idea of what's a toplevel form is even more screwed up
+ than the example in IR1-3 would suggest, since COMPILE-FILE and
+ COMPILE both print both "right now!" messages when compiling the
+ following code,
+ (LAMBDA (X)
+ (COND (X
+ (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
+ (PRINT "yes! right now!"))
+ "yes!")
+ (T
+ (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
+ (PRINT "no! right now!"))
+ "no!")))
+ and while EVAL doesn't print the "right now!" messages, the first
+ FUNCALL on the value returned by EVAL causes both of them to be printed.
+
+IR1-4:
+ The system accepts DECLAIM in most places where DECLARE would be
+ accepted, without even issuing a warning. ANSI allows this, but since
+ it's fairly easy to mistype DECLAIM instead of DECLARE, and the
+ meaning is rather different, and it's unlikely that the user
+ has a good reason for doing DECLAIM not at top level, it would be
+ good to issue a STYLE-WARNING when this happens. A possible
+ fix would be to issue STYLE-WARNINGs for DECLAIMs not at top level,
+ or perhaps to issue STYLE-WARNINGs for any EVAL-WHEN not at top level.
+ [This is considered an IR1-interpreter-related bug because until
+ EVAL-WHEN is rewritten, which won't happen until after the IR1
+ 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.]