0.pre7.86.flaky7.26:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 87e1f35..cce7d24 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -1227,7 +1227,115 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   This function returns its argument. But after removing percents it
   does not work: "Result of (1- n) is not a function".
 
   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. 
+
+    

 KNOWN BUGS RELATED TO THE IR1 INTERPRETER
 
 (Now that the IR1 interpreter has gone away, these should be 
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER
 
 (Now that the IR1 interpreter has gone away, these should be