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
(during macroexpansion of IN-PACKAGE,
during macroexpansion of DEFFOO)
-13:
- Floating point infinities are screwed up. [When I was converting CMU CL
- to SBCL, I was looking for complexity to delete, and I thought it was safe
- to just delete support for floating point infinities. It wasn't: they're
- generated by the floating point hardware even when we remove support
- for them in software. Also we claim the :IEEE-FLOATING-POINT feature,
- and I think that means we should support infinities.-- WHN] Support
- for them should be restored.
-
-14:
- The ANSI syntax for non-STANDARD method combination types in CLOS is
- (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN))
- (DEFMETHOD FOO PROGN ((X BAR)) (PRINT 'NUMBER))
- If you mess this up, omitting the PROGN qualifier in in DEFMETHOD,
- (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN))
- (DEFMETHOD FOO ((X BAR)) (PRINT 'NUMBER))
- the error mesage is not easy to understand:
- INVALID-METHOD-ERROR was called outside the dynamic scope
- of a method combination function (inside the body of
- DEFINE-METHOD-COMBINATION or a method on the generic
- function COMPUTE-EFFECTIVE-METHOD).
- It would be better if it were more informative, a la
- The method combination type for this method (STANDARD) does
- not match the method combination type for the generic function
- (PROGN).
- Also, after you make the mistake of omitting the PROGN qualifier
- on a DEFMETHOD, doing a new DEFMETHOD with the correct qualifier
- no longer works:
- (DEFMETHOD FOO PROGN ((X BAR)) (PRINT 'NUMBER))
- gives
- INVALID-METHOD-ERROR was called outside the dynamic scope
- of a method combination function (inside the body of
- DEFINE-METHOD-COMBINATION or a method on the generic
- function COMPUTE-EFFECTIVE-METHOD).
- This is not very helpful..
-
15:
(SUBTYPEP '(FUNCTION (T BOOLEAN) NIL)
'(FUNCTION (FIXNUM FIXNUM) NIL)) => T, T
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.
-
-24:
- Right now, when COMPILE-FILE has a read error, it actually pops
- you into the debugger before giving up on the file. It should
- instead handle the error, perhaps issuing (and handling)
- a secondary error "caught ERROR: unrecoverable error during compilation"
- and then return with FAILURE-P true,
-
-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.
-
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,
45:
a slew of floating-point-related errors reported by Peter Van Eynde
on July 25, 2000:
- a: (SQRT -9.0) fails, because SB-KERNEL::COMPLEX-SQRT is undefined.
- Similarly, COMPLEX-ASIN, COMPLEX-ACOS, COMPLEX-ACOSH, and others
- aren't found.
+ a: (fixed in sbcl-0.6.11.25)
b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and
should probably be 1.4012985e-45. In SBCL,
(/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller
(EXPT 10.0d0 1000)
PVE's regression tests want them to raise errors. SBCL
generates the infinities instead, which may or may not be
- conforming behavior, but then blow it by being unable to
- output the infinities, since support for infinities is generally
- broken, and in particular SB-IMPL::OUTPUT-FLOAT-INFINITY is
- undefined.
+ conforming behavior.
d: (in section12.erg) various forms a la
(FLOAT 1 DOUBLE-FLOAT-EPSILON)
don't give the right behavior.
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).
-
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
(I haven't tried to investigate this bug enough to guess whether
there might be any user-level symptoms.)
-87:
- Despite what the manual says, (DECLAIM (SPEED 0)) doesn't cause
- things to be byte compiled. This seems to be true in cmucl-2.4.19,
- too: (COMPILE-FILE .. :BYTE-COMPILE T) causes byte-compilation,
- but ordinary COMPILE-FILE of a file containing (DECLAIM (SPEED 0))
- does not.
-
-88:
- The type system doesn't understand that the intersection of the
- types (MEMBER :FOO) and (OR KEYWORD NULL) is (MEMBER :FOO).
-
-89:
- The type system doesn't understand the the intersection of the types
- KEYWORD and (OR KEYWORD NULL) is KEYWORD, perhaps because KEYWORD
- is itself an intersection type and that causes technical problems
- with the simplification.
+90:
+ a latent cross-compilation/bootstrapping bug: The cross-compilation
+ host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp
+ and possibly elsewhere. Instead, we should use the target system's
+ CHAR-CODE-LIMIT. This will probably cause problems if we try to
+ bootstrap on a system which uses a different value of CHAR-CODE-LIMIT
+ than SBCL does.
+
+91:
+ (subtypep '(or (integer -1 1)
+ unsigned-byte)
+ '(or (rational -1 7)
+ unsigned-byte
+ (integer -1 1))) => NIL,T
+ An analogous problem with SINGLE-FLOAT and REAL types was fixed in
+ sbcl-0.6.11.22, but some peculiarites of the RATIO type make it
+ awkward to generalize the fix to INTEGER and RATIONAL. It's not
+ clear what's the best fix. (See the "bug in type handling" discussion
+ on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.)
+
+93:
+ In sbcl-0.6.11.26, (COMPILE 'IN-HOST-COMPILATION-MODE) in
+ src/cold/shared.lisp doesn't correctly translate the
+ interpreted function
+ (defun in-host-compilation-mode (fn)
+ (let ((*features* (cons :sb-xc-host *features*))
+ ;; the CROSS-FLOAT-INFINITY-KLUDGE, as documented in
+ ;; base-target-features.lisp-expr:
+ (*shebang-features* (set-difference *shebang-features*
+ '(:sb-propagate-float-type
+ :sb-propagate-fun-type))))
+ (with-additional-nickname ("SB-XC" "SB!XC")
+ (funcall fn))))
+ No error is reported by the compiler, but when the function is executed,
+ it causes an error
+ TYPE-ERROR in SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
+ (:LINUX :X86 :IEEE-FLOATING-POINT :SB-CONSTRAIN-FLOAT-TYPE :SB-TEST
+ :SB-INTERPRETER :SB-DOC :UNIX ...) is not of type SYMBOL.
+
+94a:
+ Inconsistencies between derived and declared VALUES return types for
+ DEFUN aren't checked very well. E.g. the logic which successfully
+ catches problems like
+ (declaim (ftype (function (fixnum) float) foo))
+ (defun foo (x)
+ (declare (type integer x))
+ (values x)) ; wrong return type, detected, gives warning, good!
+ fails to catch
+ (declaim (ftype (function (t) (values t t)) bar))
+ (defun bar (x)
+ (values x)) ; wrong number of return values, no warning, bad!
+ The cause of this is seems to be that (1) the internal function
+ VALUES-TYPES-EQUAL-OR-INTERSECT used to make the check handles its
+ arguments symmetrically, and (2) when the type checking code was
+ written back when when SBCL's code was still CMU CL, the intent
+ was that this case
+ (declaim (ftype (function (t) t) bar))
+ (defun bar (x)
+ (values x x)) ; wrong number of return values; should give warning?
+ not be warned for, because a two-valued return value is considered
+ to be compatible with callers who expects a single value to be
+ returned. That intent is probably not appropriate for modern ANSI
+ Common Lisp, but fixing this might be complicated because of other
+ divergences between auld-style and new-style handling of
+ multiple-VALUES types. (Some issues related to this were discussed
+ on cmucl-imp at some length sometime in 2000.)
+
+95:
+ The facility for dumping a running Lisp image to disk gets confused
+ when run without the PURIFY option, and creates an unnecessarily large
+ core file (apparently representing memory usage up to the previous
+ high-water mark). Moreover, when the file is loaded, it confuses the
+ GC, so that thereafter memory usage can never be reduced below that
+ level.
+
+96:
+ The TRACE facility can't be used on some kinds of functions.
+ (Basically, the breakpoint facility was incompletely implemented
+ in the X86 port of CMU CL, and hasn't been fixed in SBCL.)
+
+98:
+ In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU
+ CL), out-of-line structure slot setters are horribly inefficient
+ whenever the type of the slot is declared, because out-of-line
+ structure slot setters are implemented as closures to save space,
+ so the compiler doesn't compile the type test into code, but
+ instead just saves the type in a lexical closure and interprets it
+ at runtime.
+ A proper solution involves deciding whether it's really worth
+ saving space by implementing structure slot accessors as closures.
+ (If it's not worth it, the problem vanishes automatically. If it
+ is worth it, there are hacks we could use to force type tests to
+ be compiled anyway, and even shared. E.g. we could implement
+ an EQUAL hash table mapping from types to compiled type tests,
+ and save the appropriate compiled type test as part of each lexical
+ closure; or we could make the lexical closures be placeholders
+ which overwrite their old definition as a lexical closure with
+ a new compiled definition the first time that they're called.)
+ As a workaround for the problem, #'(SETF FOO) expressions can
+ be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
+(defmacro efficient-setf-function (place-function-name)
+ (or #+sbcl (and (sb-impl::info :function :accessor-for place-function-name)
+ ;; a workaround for the problem, encouraging the
+ ;; inline expansion of the structure accessor, so
+ ;; that the compiler can optimize its type test
+ (let ((new-value (gensym "NEW-VALUE-"))
+ (structure-value (gensym "STRUCTURE-VALUE-")))
+ `(lambda (,new-value ,structure-value)
+ (setf (,place-function-name ,structure-value)
+ ,new-value))))
+ ;; no problem, can just use the ordinary expansion
+ `(function (setf ,place-function-name))))
+
+99:
+ DESCRIBE interacts poorly with *PRINT-CIRCLE*, e.g. the output from
+ (let ((*print-circle* t)) (describe (make-hash-table)))
+ is weird,
+ #<HASH-TABLE :TEST EQL :COUNT 0 {90BBFC5}> is an . (EQL)
+ Its SIZE is 16.
+ Its REHASH-SIZE is 1.5. Its REHASH-THRESHOLD is . (1.0)
+ It holds 0 key/value pairs.
+ where the ". (EQL)" and ". (1.0)" substrings are screwups.
+ (This is likely a pretty-printer problem which happens to
+ be exercised by DESCRIBE, not actually a DESCRIBE problem.)
+
+100:
+ There's apparently a bug in CEILING optimization which caused
+ Douglas Crosher to patch the CMU CL version. Martin Atzmueller
+ applied the patches to SBCL and they didn't seem to cause problems
+ (as reported sbcl-devel 2001-05-04). However, since the patches
+ modify nontrivial code which was apparently written incorrectly
+ the first time around, until regression tests are written I'm not
+ comfortable merging the patches in the CVS version of SBCL.
+
+101:
+ The error message for calls to structure accessors with the
+ wrong number of arguments is confusing and of the wrong
+ condition class (TYPE-ERROR instead of PROGRAM-ERROR):
+ * (defstruct foo x y)
+ * (foo-x)
+ debugger invoked on condition of type SIMPLE-TYPE-ERROR:
+ Structure for accessor FOO-X is not a FOO:
+ 301988783
+
+102:
+ As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI
+ requires that SYMBOL-MACROLET refuse to rebind special variables,
+ but SBCL doesn't do this. (Also as reported by AL in the same
+ message, SBCL depended on this nonconforming behavior to build
+ itself, because of the way that **CURRENT-SEGMENT** was implemented.
+ As of sbcl-0.6.12.x, this dependence on the nonconforming behavior
+ has been fixed, but the nonconforming behavior remains.)
+
+103:
+ As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI's
+ definition of (LOOP .. DO ..) requires that the terms following
+ DO all be compound forms. SBCL's implementation of LOOP allows
+ non-compound forms (like the bare symbol COUNT, in his example)
+ here.
+
+104:
+ (DESCRIBE 'SB-ALIEN:DEF-ALIEN-TYPE) reports the macro argument list
+ incorrectly:
+ DEF-ALIEN-TYPE is
+ an external symbol
+ in #<PACKAGE "SB-ALIEN">.
+ Macro-function: #<FUNCTION "DEF!MACRO DEF-ALIEN-TYPE" {19F4A39}>
+ Macro arguments: (#:whole-470 #:environment-471)
+ On Sat, May 26, 2001 09:45:57 AM CDT it was compiled from:
+ /usr/stuff/sbcl/src/code/host-alieneval.lisp
+ Created: Monday, March 12, 2001 07:47:43 AM CST
+
+105:
+ (DESCRIBE 'STREAM-READ-BYTE)
+
+106:
+ (reported by Eric Marsden on cmucl-imp 2001-06-15)
+ Executing
+ (TYPEP 0 '(COMPLEX (EQL 0)))
+ signals an error in sbcl-0.6.12.34,
+ The component type for COMPLEX is not numeric: (EQL 0)
+ This is funny since sbcl-0.6.12.34 knows
+ (SUBTYPEP '(EQL 0) 'NUMBER) => T
+
+108:
+ (TIME (ROOM T)) reports more than 200 Mbytes consed even for
+ a clean, just-started SBCL system. And it seems to be right:
+ (ROOM T) can bring a small computer to its knees for a *long*
+ 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)
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.
projects / sbcl.git / blobdiff