to really grok function declarations.
7:
- The "byte compiling top-level form:" output ought to be condensed.
+ The "compiling top-level form:" output ought to be condensed.
Perhaps any number of such consecutive lines ought to turn into a
- single "byte compiling top-level forms:" line.
+ single "compiling top-level forms:" line.
10:
The way that the compiler munges types with arguments together
munge12egnum
NIL
-23:
- When too many files are opened, OPEN will fail with an
- uninformative error message
- error in function OPEN: error opening #P"/tmp/foo.lisp": NIL
- instead of saying that too many files are open.
-
-26:
- reported by Sam Steingold on the cmucl-imp mailing list 12 May 2000:
- Also, there is another bug: `array-displacement' should return an
- array or nil as first value (as per ANSI CL), while CMUCL declares
- it as returning an array as first value always.
- (Actually, I think the old CMU CL version in SBCL never returns NIL,
- i.e. it's not just a declaration problem, but the definition doesn't
- behave ANSIly.)
-
27:
Sometimes (SB-EXT:QUIT) fails with
Argh! maximum interrupt nesting depth (4096) exceeded, exiting
E.g. compiling and loading
(DECLAIM (OPTIMIZE (SAFETY 3)))
(DEFUN FACTORIAL (X) (GAMMA (1+ X)))
- (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE) FACTORIAL)))
+ (DEFUN GAMMA (X) X)
+ (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE)) FACTORIAL))
(DEFUN FOO (X)
(COND ((> (FACTORIAL X) 1.0E6)
(FORMAT T "too big~%"))
that arbitrary functions check their argument types. (It might
make sense to add another flag (CHECKED?) to DEFKNOWN to
identify functions which *do* check their argument types.)
+ (Also, verify that the compiler handles declared function
+ return types as assertions.)
38:
DEFMETHOD doesn't check the syntax of &REST argument lists properly,
c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
it binds is declared SPECIAL inside.
-49:
- LOOP bugs reported by Peter Van Eynde July 25, 2000:
- a: (LOOP WITH (A B) DO (PRINT 1)) is a syntax error according to
- the definition of WITH clauses given in the ANSI spec, but
- compiles and runs happily in SBCL.
- b: a messy one involving package iteration:
-interpreted Form: (LET ((PACKAGE (MAKE-PACKAGE "LOOP-TEST"))) (INTERN "blah" PACKAGE) (LET ((BLAH2 (INTERN "blah2" PACKAGE))) (EXPORT BLAH2 PACKAGE)) (LIST (SORT (LOOP FOR SYM BEING EACH PRESENT-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<)) (SORT (LOOP FOR SYM BEING EACH EXTERNAL-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<))))
-Should be: (("blah" "blah2") ("blah2"))
-SBCL: (("blah") ("blah2"))
- * (LET ((X 1)) (LOOP FOR I BY (INCF X) FROM X TO 10 COLLECT I))
- doesn't work -- SBCL's LOOP says BY isn't allowed in a FOR clause.
-
50:
type system errors reported by Peter Van Eynde July 25, 2000:
a: (SUBTYPEP 'BIGNUM 'INTEGER) => NIL, NIL
The implementation of #'+ returns its single argument without
type checking, e.g. (+ "illegal") => "illegal".
-55:
- In sbcl-0.6.7, there is no doc string for CL:PUSH, probably
- because it's defined with the DEFMACRO-MUNDANELY macro and something
- is wrong with doc string setting in that macro.
-
56:
Attempting to use COMPILE on something defined by DEFMACRO fails:
(DEFMACRO FOO (X) (CONS X X))
CLOS methods, and then expressing the solutions to stuff like this
should become much more straightforward. -- WHN 2001-03-14
-59:
- CL:*DEFAULT-PATHNAME-DEFAULTS* doesn't behave as ANSI suggests (reflecting
- current working directory). And there's no supported way to update
- or query the current working directory (a la Unix "chdir" and "pwd"),
- which is functionality that ILISP needs (and currently gets with low-level
- hacks).
- When this is fixed, probably the more-or-less-parallel Unix-level
- hacks
- DEFAULT-DIRECTORY
- %SET-DEFAULT-DIRECTORY
- etc.?
- should go away. Also we need to figure out what's the proper way to
- deal with the interaction of users assigning new values to
- *DEFAULT-PATHNAME-DEFAULTS* and cores being saved and restored.
- (Perhaps just make restoring from a save always overwrite the old
- value with the new Unix-level default directory?)
-
60:
The debugger LIST-LOCATIONS command doesn't work properly.
rightward of the correct location.
65:
- (probably related to bug #70)
+ (probably related to bug #70; maybe related to bug #109)
As reported by Carl Witty on submit@bugs.debian.org 1999-05-08,
compiling this file
(in-package "CL-USER")
or at least issue a warning.
70:
- (probably related to bug #65)
+ (probably related to bug #65; maybe related to bug #109)
The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
forms. E.g.
(DEFUN FIND-BEFORE (ITEM SEQUENCE &KEY (TEST #'EQL))
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
time trying to GC afterwards. Surely there's some more economical
way to implement (ROOM T).
+109:
+ reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
+ collection:
+ ;;; This file fails to compile.
+ ;;; Maybe this bug is related to bugs #65, #70 in the BUGS file.
+ (in-package :cl-user)
+ (defun tst2 ()
+ (labels
+ ((eff (&key trouble)
+ (eff)
+ ;; nil
+ ;; Uncomment and it works
+ ))
+ (eff)))
+ In SBCL 0.6.12.42, the problem is
+ internal error, failed AVER:
+ "(COMMON-LISP:EQ (SB!C::LAMBDA-TAIL-SET SB!C::CALLER)
+ (SB!C::LAMBDA-TAIL-SET (SB!C::LAMBDA-HOME SB!C::CALLEE)))"
+
+110:
+ reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
+ collection:
+ ;;; The compiler is flushing the argument type test, and the default
+ ;;; case in the cond, so that calling with say a fixnum 0 causes a
+ ;;; SIGBUS.
+ (declaim (optimize (safety 2) (speed 3)))
+ (defun tst (x)
+ (declare (type (or string stream) x))
+ (cond ((typep x 'string) 'string)
+ ((typep x 'stream) 'stream)
+ (t
+ 'none)))
+ The symptom in sbcl-0.6.12.42 on OpenBSD is actually (TST 0)=>STREAM
+ (not the SIGBUS reported in the comment) but that's broken too;
+ type declarations are supposed to be treated as assertions unless
+ SAFETY 0, so we should be getting a TYPE-ERROR.
+
+111:
+ reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
+ collection:
+ (in-package :cl-user)
+ ;;; Produces an assertion failures when compiled.
+ (defun foo (z)
+ (declare (type (or (function (t) t) null) z))
+ (let ((z (or z #'identity)))
+ (declare (type (function (t) t) z))
+ (funcall z 1)))
+ The error in sbcl-0.6.12.42 is
+ internal error, failed AVER:
+ "(COMMON-LISP:NOT (COMMON-LISP:EQ SB!C::CHECK COMMON-LISP:T))"
+
+112:
+ reported by Martin Atzmueller 2001-06-25; taken from CMU CL bugs
+ collection; apparently originally reported by Bruno Haible
+ (in-package :cl-user)
+ ;;; From: Bruno Haible
+ ;;; Subject: scope of SPECIAL declarations
+ ;;; It seems CMUCL has a bug relating to the scope of SPECIAL
+ ;;; declarations. I observe this with "CMU Common Lisp 18a x86-linux
+ ;;; 1.4.0 cvs".
+ (let ((x 0))
+ (declare (special x))
+ (let ((x 1))
+ (let ((y x))
+ (declare (special x)) y)))
+ ;;; Gives: 0 (this should return 1 according to CLHS)
+ (let ((x 0))
+ (declare (special x))
+ (let ((x 1))
+ (let ((y x) (x 5))
+ (declare (special x)) y)))
+ ;;; Gives: 1 (correct).
+ The reported results match what we get from the interpreter
+ in sbcl-0.6.12.42.
+
+113:
+ reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
+ collection:
+ (in-package :cl-user)
+ ;;; From: David Gadbois <gadbois@cyc.com>
+ ;;;
+ ;;; Logical pathnames aren't externalizable.
+ ;;; Test case:
+ (let ((tempfile "/tmp/test.lisp"))
+ (setf (logical-pathname-translations "XXX")
+ '(("XXX:**;*.*" "/tmp/**/*.*")))
+ (with-open-file (out tempfile :direction :output)
+ (write-string "(defvar *path* #P\"XXX:XXX;FOO.LISP\")" out))
+ (compile-file tempfile))
+ The error message in sbcl-0.6.12.42 is
+ ; caught ERROR:
+ ; (while making load form for #<SB-IMPL::LOGICAL-HOST "XXX">)
+ ; A logical host can't be dumped as a constant: #<SB-IMPL::LOGICAL-HOST "XXX">
+
+115:
+ reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
+ collection:
+ (in-package :cl-user)
+ ;;; The following invokes a compiler error.
+ (declaim (optimize (speed 2) (debug 3)))
+ (defun tst ()
+ (flet ((m1 ()
+ (unwind-protect nil)))
+ (if (catch nil)
+ (m1)
+ (m1))))
+ The error message in sbcl-0.6.12.42 is
+ internal error, failed AVER:
+ "(COMMON-LISP:EQ (SB!C::TN-ENVIRONMENT SB!C:TN) SB!C::TN-ENV)"
+
+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)
+
+127:
+ The DEFSTRUCT section of the ANSI spec, in the :CONC-NAME section,
+ specifies a precedence rule for name collisions between slot accessors of
+ structure classes related by inheritance. As of 0.7.0, SBCL still
+ doesn't follow it.
+
+
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.
+(Now that the IR1 interpreter has gone away, these should be
+relatively straightforward to fix.)
IR1-4:
The system accepts DECLAIM in most places where DECLARE would be
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.]
+
+IR1-6:
+ (another wishlist thing..) Reimplement DEFMACRO to be basically
+ like DEFMACRO-MUNDANELY, just using EVAL-WHEN.