X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=5df3d1b4e304d99ac4f08373e50061de7d01de5b;hb=dec94b039e8ec90baf21463df839a6181de606f6;hp=dc965959453a458299c36a092607d0e17adb3688;hpb=cbaa1997bb097a55d108df592ac3b7eb4a703fff;p=sbcl.git diff --git a/BUGS b/BUGS index dc96595..5df3d1b 100644 --- a/BUGS +++ b/BUGS @@ -88,9 +88,9 @@ WORKAROUND: 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 @@ -118,42 +118,6 @@ WORKAROUND: (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 @@ -219,26 +183,6 @@ WORKAROUND: 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 @@ -299,7 +243,8 @@ returning an array as first value always. 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~%")) @@ -322,6 +267,8 @@ returning an array as first value always. 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, @@ -365,9 +312,7 @@ returning an array as first value always. 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 @@ -381,10 +326,7 @@ returning an array as first value always. (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. @@ -445,18 +387,6 @@ returning an array as first value always. 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 @@ -512,11 +442,6 @@ SBCL: (("blah") ("blah2")) 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)) @@ -538,13 +463,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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. @@ -609,7 +527,7 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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") @@ -706,7 +624,7 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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)) @@ -779,17 +697,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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 @@ -825,82 +732,466 @@ Error in function C::GET-LAMBDA-TO-COMPILE: (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, + # 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 #. + Macro-function: # + 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 + ;;; + ;;; 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 #) + ; A logical host can't be dumped as a constant: # + +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 + (#) + 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 @@ -915,3 +1206,7 @@ IR1-4: 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.