X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=2f5f538d20cda7fba9265c26efed77dee6cb5422;hb=ba7659c92f2b7fac7e9532a3db9114c5bdc4ab55;hp=00127a1c8335e7a374961365ca0add7247b4509e;hpb=2d75f4246b8451a9c2c95cd36673d98c82c9845f;p=sbcl.git diff --git a/BUGS b/BUGS index 00127a1..2f5f538 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 @@ -1017,21 +1017,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: ; (while making load form for #) ; A logical host can't be dumped as a constant: # -114: - reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs - collection: - (in-package :cl-user) - ;;; This file causes the byte compiler to fail. - (declaim (optimize (speed 0) (safety 1))) - (defun tst1 () - (values - (multiple-value-list - (catch 'a - (return-from tst1))))) - The error message in sbcl-0.6.12.42 is - internal error, failed AVER: - "(COMMON-LISP:EQUAL (SB!C::BYTE-BLOCK-INFO-START-STACK SB!INT:INFO) SB!C::STACK)" - 115: reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs collection: @@ -1090,42 +1075,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: Raymond Toy comments that this is tricky on the X86 since its FPU uses 80-bit precision internally. -119: - a bug in the byte compiler and/or interpreter: Compile - (IN-PACKAGE :CL-USER) - (DECLAIM (OPTIMIZE (SPEED 0) (SAFETY 1) (DEBUG 1))) - (DEFUN BAR (&REST DIMS) - (IF (EVERY #'INTEGERP DIMS) - 1 - 2)) - then execute (BAR '(1 2 3 4)). In sbcl-0.pre7.14.flaky4.8 - this gives a TYPE-ERROR, - The value #:UNINITIALIZED-EVAL-STACK-ELEMENT is not - of type (MOD 536870911). - The same error will probably occur in earlier versions as well, - although the name of the uninitialized-element placeholder will - be shorter. - - The same thing happens if the compiler macro expansion of - EVERY into MAP is hand-expanded: - (defun bar2 (dims) - (if (block blockname - (map nil - (lambda (dim) - (let ((pred-value (funcall #'integerp dim))) - (unless pred-value - (return-from blockname - nil)))) - dims) - t) - 1 - 2)) - CMU CL doesn't have this compiler macro expansion, so it was - immune to the original bug in BAR, but once we hand-expand it - into BAR2, CMU CL 18c has the same bug. (Run (BAR '(NIL NIL)).) - - The native compiler handles it fine, both in SBCL and in CMU CL. - 120a: The compiler incorrectly figures the return type of (DEFUN FOO (FRAME UP-FRAME) @@ -1238,6 +1187,133 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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 + # 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. KNOWN BUGS RELATED TO THE IR1 INTERPRETER