+ (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.
+
+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.
+
+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.
+
+84:
+ (SUBTYPEP '(SATISFIES SOME-UNDEFINED-FUN) NIL)=>NIL,T (should be NIL,NIL)
+
+85:
+ Internally the compiler sometimes evaluates
+ (sb-kernel:type/= (specifier-type '*) (specifier-type t))
+ (I stumbled across this when I added an
+ (assert (not (eq type1 *wild-type*)))
+ in the NAMED :SIMPLE-= type method.) '* isn't really a type, and
+ in a type context should probably be translated to T, and so it's
+ probably to ask whether it's equal to the T type and then (using the
+ EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.
+ (I haven't tried to investigate this bug enough to guess whether
+ there might be any user-level symptoms.)
+
+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.
+
+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.)
+
+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)
+ (and APD pointed out on sbcl-devel 2001-12-29 that it's the same
+ as bug 50e)
+
+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)
+
+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.
+
+128:
+ READ-SEQUENCE doesn't work for Gray streams. (reported by Nathan
+ Froyd sbcl-devel 2001-10-15) As per subsequent discussion on the
+ list, the Gray streams proposal doesn't mention READ-SEQUENCE and
+ WRITE-SEQUENCE because it predates them, generalizing it to
+ cover them is an obvious extension, ACL does it, and there's a
+ patch for for CMU CL which does it too.
+
+129:
+ insufficient syntax checking in MACROLET:
+ (defun foo (x)
+ (macrolet ((defmacro bar (z) `(+ z z)))
+ (bar x)))
+ shouldn't compile without error (because of the extra DEFMACRO symbol).
+
+130:
+ reported by Alexey Dejneka on sbcl-devel 2001-11-03
+ (defun x (x)
+ "Return X if X is a non-negative integer."
+ (let ((step (lambda (%funcall)
+ (lambda (n)
+ (cond ((= n 0) 0)
+ (t (1+ (funcall %funcall (1- n)))))))))
+ (funcall
+ ((lambda (a)
+ (funcall step (lambda (n)
+ (funcall (funcall a a) n))))
+ (lambda (a)
+ (funcall step (lambda (n)
+ (funcall (funcall a a) n)))))
+ x)))
+ This function returns its argument. But after removing percents it
+ does not work: "Result of (1- n) is not a function".
+
+131:
+ As of sbcl-0.pre7.86.flaky7.3, the cross-compiler, and probably
+ the CL:COMPILE function (which is based on the same %COMPILE
+ mechanism) get confused by
+(defun sxhash (x)
+ (labels ((sxhash-number (x)
+ (etypecase x
+ (fixnum (sxhash x)) ; through DEFTRANSFORM
+ (integer (sb!bignum:sxhash-bignum x))
+ (single-float (sxhash x)) ; through DEFTRANSFORM
+ (double-float (sxhash x)) ; through DEFTRANSFORM
+ #!+long-float (long-float (error "stub: no LONG-FLOAT"))
+ (ratio (let ((result 127810327))
+ (declare (type fixnum result))
+ (mixf result (sxhash-number (numerator x)))
+ (mixf result (sxhash-number (denominator x)))
+ result))
+ (complex (let ((result 535698211))
+ (declare (type fixnum result))
+ (mixf result (sxhash-number (realpart x)))
+ (mixf result (sxhash-number (imagpart x)))
+ result))))
+ (sxhash-recurse (x &optional (depthoid +max-hash-depthoid+))
+ (declare (type index depthoid))
+ (typecase x
+ (list
+ (if (plusp depthoid)
+ (mix (sxhash-recurse (car x) (1- depthoid))
+ (sxhash-recurse (cdr x) (1- depthoid)))
+ 261835505))
+ (instance
+ (if (typep x 'structure-object)
+ (logxor 422371266
+ (sxhash ; through DEFTRANSFORM
+ (class-name (layout-class (%instance-layout x)))))
+ 309518995))
+ (symbol (sxhash x)) ; through DEFTRANSFORM
+ (number (sxhash-number x))
+ (array
+ (typecase x
+ (simple-string (sxhash x)) ; through DEFTRANSFORM
+ (string (%sxhash-substring x))
+ (bit-vector (let ((result 410823708))
+ (declare (type fixnum result))
+ (dotimes (i (min depthoid (length x)))
+ (mixf result (aref x i)))
+ result))
+ (t (logxor 191020317 (sxhash (array-rank x))))))
+ (character
+ (logxor 72185131
+ (sxhash (char-code x)))) ; through DEFTRANSFORM
+ (t 42))))
+ (sxhash-recurse x)))
+ complaining "function called with two arguments, but wants exactly
+ one" about SXHASH-RECURSE. (This might not be strictly a new bug,
+ since IIRC post-fork CMU CL has also had problems with &OPTIONAL
+ arguments in FLET/LABELS: it might be an old Python bug which is
+ only exercised by the new arrangement of the SBCL compiler.)
+
+132:
+ Trying to compile
+ (DEFUN FOO () (CATCH 0 (PRINT 1331)))
+ gives an error
+ #<SB-C:TN '0!1> is not valid as the second argument to VOP:
+ SB-C:MAKE-CATCH-BLOCK,
+ since the TN's primitive type SB-VM::POSITIVE-FIXNUM doesn't allow
+ any of the SCs allowed by the operand restriction:
+ (SB-VM::DESCRIPTOR-REG)
+ The (CATCH 0 ...) construct is bad style (because of unportability
+ of EQ testing of numbers) but it is legal, and shouldn't cause an
+ internal compiler error. (This error occurs in sbcl-0.6.13 and in
+ 0.pre7.86.flaky7.14.)
+
+133:
+ Trying to compile something like
+ (sb!alien:def-alien-routine "breakpoint_remove" sb!c-call:void
+ (code-obj sb!c-call:unsigned-long)
+ (pc-offset sb!c-call:int)
+ (old-inst sb!c-call:unsigned-long))
+ in SBCL-0.pre7.86.flaky7.22 after warm init fails with an error
+ cannot use values types here
+ probably because the SB-C-CALL:VOID type gets translated to (VALUES).
+ It should be valid to use VOID for a function return type, so perhaps
+ instead of calling SPECIFIER-TYPE (which excludes all VALUES types
+ automatically) we should call VALUES-SPECIFIER-TYPE and handle VALUES
+ types manually, allowing the special case (VALUES) but still excluding
+ all more-complex VALUES types.
+
+134:
+ (reported by Alexey Dejneka sbcl-devel 2001-12-07)
+ (let ((s '((1 2 3))))
+ (eval (eval ``(vector ,@',@s))))
+
+ should return #(1 2 3), instead of this it causes a reader error.
+
+ Interior call of BACKQUOTIFY erroneously optimizes ,@': it immediately
+ splices the temporal representation of ,@S.
+
+135:
+ Ideally, uninterning a symbol would allow it, and its associated
+ FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
+ at least as of sbcl-0.7.0, this isn't the case. Information about
+ FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp
+ essentially in ordinary (non-weak) hash tables keyed by symbols.
+ Thus, once a system has an entry in this system, it tends to live
+ forever, even when it is uninterned and all other references to it
+ are lost.
+
+136:
+ (reported by Arnaud Rouanet on cmucl-imp 2001-12-18)
+ (defmethod foo ((x integer))
+ x)
+ (defmethod foo :around ((x integer))
+ (let ((x (1+ x)))
+ (call-next-method)))
+ Now (FOO 3) should return 3, but instead it returns 4.
+
+137:
+ (SB-DEBUG:BACKTRACE) output should start with something
+ including the name BACKTRACE, not (as in 0.pre7.88)
+ just "0: (\"hairy arg processor\" ...)". In general
+ the names in BACKTRACE are all screwed up compared to
+ the nice useful names in 0.6.13.
+
+ Note for those who observe that this is an annoying
+ bug and doesn't belong in a release: See the "note for the
+ ambitious", below.
+
+ Note for the ambitious: This is an important bug and I'd
+ really like to fix it and spent many hours on it. The
+ obvious ways to fix it are hard, because the underlying
+ infrastructure seems to be rather broken.
+ * There are two mostly-separate systems for storing names,
+ the in-the-function-object system used by e.g.
+ CL:FUNCTION-LAMBDA-EXPRESSION and the
+ in-the-DEBUG-FUN-object system used by e.g. BACKTRACE.
+ The code as of sbcl-0.pre7.94 is smart enough to set
+ up the first value, but not the second (because I naively
+ assumed that one mechanism is enough, and didn't proof
+ read the entire system to see whether there might be
+ another mechanism?! argh...)
+ * The systems are not quite separate, but instead weirdly and
+ fragilely coupled by the FUN-DEBUG-FUN algorithm.
+ * If you try to refactor this dain bramage away, reducing
+ things to a single system -- I tried to add a
+ %SIMPLE-FUN-DEBUG-FUN slot, planning eventually to get
+ rid of the old %SIMPLE-FUN-NAME slot in favor of indirection
+ through the new slot -- you get torpedoed by the fragility
+ of the SIMPLE-FUN primitive object. Just adding the
+ new slot, without making any other changes in the system,
+ is enough to make the system fail with what look like
+ memory corruption problems in warm init.
+ But please do fix some or all of the problem, I'm tired
+ of messing with it. -- WHN 2001-12-22