X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=sidebyside;f=BUGS;h=325068df4d995565523a8a92b6afd8df8a5da76c;hb=7b384da95e6a30e1434523213aeeed3a90448c78;hp=7e35c3c3b755ad88e09e1213deb95e142a372e2e;hpb=e3f68bde025bd0602cf554e1eaf5935aaa74662a;p=sbcl.git diff --git a/BUGS b/BUGS index 7e35c3c..325068d 100644 --- a/BUGS +++ b/BUGS @@ -184,15 +184,6 @@ WORKAROUND: (FLOAT 1 DOUBLE-FLOAT-EPSILON) don't give the right behavior. -46: - type safety errors reported by Peter Van Eynde July 25, 2000: - k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is - not a binary input stream, but instead cheerfully reads from - string-input streams, e.g. (MAKE-STRING-INPUT-STREAM "abc"). - [ Bug was reported as "from character streams", but in 0.8.3.10 we - get correct behaviour from (WITH-OPEN-FILE (i "/dev/zero") (READ-BYTE i)) ] - - 60: The debugger LIST-LOCATIONS command doesn't work properly. (How should it work properly?) @@ -273,6 +264,11 @@ WORKAROUND: GC, so that thereafter memory usage can never be reduced below that level. + (As of 0.8.7.3 it's likely that the latter half of this bug is fixed. + The interaction between gencgc and the variables used by + save-lisp-and-die is still nonoptimal, though, so no respite from + big core files yet) + 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 @@ -333,6 +329,15 @@ WORKAROUND: time trying to GC afterwards. Surely there's some more economical way to implement (ROOM T). + Daniel Barlow doesn't know what fixed this, but observes that it + doesn't seem to be the case in 0.8.7.3 any more. Instead, (ROOM T) + in a fresh SBCL causes + + debugger invoked on a SB-INT:BUG in thread 5911: + failed AVER: "(SAP= CURRENT END)" + + unless a GC has happened beforehand. + 117: When the compiler inline expands functions, it may be that different kinds of return values are generated from different code branches. @@ -377,14 +382,6 @@ WORKAROUND: Raymond Toy comments that this is tricky on the X86 since its FPU uses 80-bit precision internally. -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. - 124: As of version 0.pre7.14, SBCL's implementation of MACROLET makes the entire lexical environment at the point of MACROLET available @@ -464,6 +461,10 @@ WORKAROUND: * '``(FOO ,@',@S) ``(FOO SB-IMPL::BACKQ-COMMA-AT S) + c. (reported by Paul F. Dietz) + * '`(lambda ,x) + `(LAMBDA (SB-IMPL::BACKQ-COMMA X)) + 143: (reported by Jesse Bouwman 2001-10-24 through the unfortunately prominent SourceForge web/db bug tracking system, which is @@ -615,12 +616,6 @@ WORKAROUND: The careful type of X is {2k} :-(. Is it really important to be able to work with unions of many intervals? -190: "PPC/Linux pipe? buffer? bug" - In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs - on the PPC/Linux platform, waiting for a zombie env process. This - is a classic symptom of buffer filling and deadlock, but it seems - only sporadically reproducible. - 191: "Miscellaneous PCL deficiencies" (reported by Alexey Dejneka sbcl-devel 2002-08-04) a. DEFCLASS does not inform the compiler about generated @@ -887,13 +882,8 @@ WORKAROUND: ; The variable Y is defined but never used. 245: bugs in disassembler - a. On X86 an immediate operand for IMUL is printed incorrectly. b. On X86 operand size prefix is not recognized. -248: "reporting errors in type specifier syntax" - (TYPEP 1 '(SYMBOL NIL)) says something about "unknown type - specifier". - 251: (defun foo (&key (a :x)) (declare (fixnum a)) @@ -978,12 +968,6 @@ WORKAROUND: Urgh... It's time to write IR1-copier. -265: - SB-EXT:RUN-PROGRAM is currently non-functional on Linux/PPC; - attempting to use it leads to segmentation violations. This is - probably because of a bogus implementation of - os_restore_fp_control(). - 266: David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix behaviour of streams with element-type (SIGNED-BYTE 8). The patch @@ -1172,20 +1156,12 @@ WORKAROUND: this problem. 288: fundamental cross-compilation issues (from old UGLINESS file) - 288a: Using host floating point numbers to represent target - floating point numbers, or host characters to represent - target characters, is theoretically shaky. (The characters - are OK as long as the characters are in the ANSI-guaranteed - character set, though, so they aren't a real problem as - long as the sources don't need anything but that.) - 288b: The compiler still makes assumptions about cross-compilation-host - implementation of ANSI CL: - 288b1: Simple bit vectors are distinct from simple vectors (in - DEFINE-STORAGE-BASE and elsewhere). (Actually, I'm not *sure* - that things would really break if this weren't so, but I - strongly suspect that they would.) - 288b2: SINGLE-FLOAT is distinct from DOUBLE-FLOAT. (This is - in a sense just one aspect of bug 288a.) + Using host floating point numbers to represent target floating point + numbers, or host characters to represent target characters, is + theoretically shaky. (The characters are OK as long as the characters + are in the ANSI-guaranteed character set, though, so they aren't a + real problem as long as the sources don't need anything but that; + the floats are a real problem.) 289: "type checking and source-transforms" a. @@ -1216,11 +1192,6 @@ WORKAROUND: the control word; however, this clobbers any change the user might have made. -295: - From Paul Dietz: - - (ash -1000000000000 -10000000000000000000) ==> 0 ;; should be -1 - 296: (reported by Adam Warner, sbcl-devel 2003-09-23) @@ -1228,3 +1199,182 @@ WORKAROUND: argument. As a result, files with Lisp pathname pattern characters (#\* or #\?, for instance) or quotation marks can cause the system to perform arbitrary behaviour. + +297: + LOOP with non-constant arithmetic step clauses suffers from overzealous + type constraint: code of the form + (loop for d of-type double-float from 0d0 to 10d0 by x collect d) + compiles to a type restriction on X of (AND DOUBLE-FLOAT (REAL + (0))). However, an integral value of X should be legal, because + successive adds of integers to double-floats produces double-floats, + so none of the type restrictions in the code is violated. + +300: (reported by Peter Graves) Function PEEK-CHAR checks PEEK-TYPE + argument type only after having read a character. This is caused + with EXPLICIT-CHECK attribute in DEFKNOWN. The similar problem + exists with =, /=, <, >, <=, >=. They were fixed, but it is probably + less error prone to have EXPLICIT-CHECK be a local declaration, + being put into the definition, instead of an attribute being kept in + a separate file; maybe also put it into SB-EXT? + +301: ARRAY-SIMPLE-=-TYPE-METHOD breaks on corner cases which can arise + in NOTE-ASSUMED-TYPES + In sbcl-0.8.7.32, compiling the file + (defun foo (x y) + (declare (type integer x)) + (declare (type (vector (or hash-table bit)) y)) + (bletch 2 y)) + (defun bar (x y) + (declare (type integer x)) + (declare (type (simple-array base (2)) y)) + (bletch 1 y)) + gives the error + failed AVER: "(NOT (AND (NOT EQUALP) CERTAINP))" + +302: Undefined type messes up DATA-VECTOR-REF expansion. + Compiling this file + (defun dis (s ei x y) + (declare (type (simple-array function (2)) s) (type ei ei)) + (funcall (aref s ei) x y)) + on sbcl-0.8.7.36/X86/Linux causes a BUG to be signalled: + full call to SB-KERNEL:DATA-VECTOR-REF + +303: "nonlinear LVARs" (aka MISC.293) + (defun buu (x) + (multiple-value-call #'list + (block foo + (multiple-value-prog1 + (eval '(values :a :b :c)) + (catch 'bar + (if (> x 0) + (return-from foo + (eval `(if (> ,x 1) + 1 + (throw 'bar (values 3 4))))))))))) + + (BUU 1) returns garbage. + + The problem is that both EVALs sequentially write to the same LVAR. + +305: + (Reported by Dave Roberts.) + Local INLINE/NOTINLINE declaration removes local FTYPE declaration: + + (defun quux (x) + (declare (ftype (function () (integer 0 10)) fee) + (inline fee)) + (1+ (fee))) + + uses generic arithmetic with INLINE and fixnum without. + +306: "Imprecise unions of array types" + a.(defun foo (x) + (declare (optimize speed) + (type (or (array cons) (array vector)) x)) + (elt (aref x 0) 0)) + (foo #((0))) => TYPE-ERROR + + relatedly, + + b.(subtypep + 'array + `(or + ,@(loop for x across sb-vm:*specialized-array-element-type-properties* + collect `(array ,(sb-vm:saetp-specifier x))))) + => NIL, T (when it should be T, T) + +307: "Problem in obsolete instance protocol" + (reported by Bruno Haible as the fourth problem in sbcl-devel + "installing sbcl" 2004-04-15) + + (progn + (defclass foo92b (foo92a) ((s :initarg :s))) + (defclass foo92a () ()) + (let ((x (make-instance 'foo92b :s 5)) (update-counter 0)) + (defclass foo92b (foo92a) ((s) (s1) (s2))) ; still subclass of foo92a + (slot-value x 's) + (defmethod update-instance-for-redefined-class + ((object foo92b) added-slots discarded-slots plist &rest initargs) + (incf update-counter)) + (make-instances-obsolete 'foo92a) + (slot-value x 's) + update-counter)) + => 0 ; should be 1 + +308: "Characters without names" + (reported by Bruno Haible sbcl-devel "character names are missing" + 2004-04-19) + (graphic-char-p (code-char 255)) + => NIL + (char-name (code-char 255)) + => NIL + + SBCL is unsure of what to do about characters with codes in the + range 128-255. Currently they are treated as non-graphic, but don't + have names, which is not compliant with the standard. Various fixes + are possible, such as + * giving them names such as NON-ASCII-128; + * reducing CHAR-CODE-LIMIT to 127 (almost certainly unpopular); + * making the characters graphic (makes a certain amount of sense); + * biting the bullet and implementing Unicode (probably quite hard). + +309: "Dubious values for implementation limits" + (reported by Bruno Haible sbcl-devel "Incorrect value of + multiple-values-limit" 2004-04-19) + (values-list (make-list 1000000)), on x86/linux, signals a stack + exhaustion condition, despite MULTIPLE-VALUES-LIMIT being + significantly larger than 1000000. There are probably similar + dubious values for CALL-ARGUMENTS-LIMIT (see cmucl-help/cmucl-imp + around the same time regarding a call to LIST on sparc with 1000 + arguments) and other implementation limit constants. + +310: "Floating point printing inaccuracy" + (reported by Bruno Haible sbcl-devel "print-read consistency for + floating point numbers" 2004-04-19) + (let ((x (/ -9.349640046247849d-21 -9.381494249123696d-11))) + (let ((y (read-from-string (write-to-string x :readably t)))) + (eql x y))) + should return T but, as of sbcl-0.8.9.51, returns NIL. + + That this is a bug in the printer is demonstrated by + (setq x1 (float -5496527/100000000000000000)) + (setq x2 (float -54965272/1000000000000000000)) + (integer-decode-float x1) => 15842660 -58 -1 + (integer-decode-float x2) => 15842661 -58 -1 + (prin1-to-string x1) => "-5.496527e-11" + (prin1-to-string x2) => "-5.496527e-11" ; should be different! + + Note also the following comment from src/code/print.lisp: + ;;; NOTE: When a number is to be printed in exponential format, it is + ;;; scaled in floating point. Since precision may be lost in this + ;;; process, the guaranteed accuracy properties of FLONUM-TO-STRING + ;;; are lost. The difficulty is that FLONUM-TO-STRING performs + ;;; extensive computations with integers of similar magnitude to that + ;;; of the number being printed. For large exponents, the bignums + ;;; really get out of hand. If bignum arithmetic becomes reasonably + ;;; fast and the exponent range is not too large, then it might become + ;;; attractive to handle exponential notation with the same accuracy + ;;; as non-exponential notation, using the method described in the + ;;; Steele and White paper. + +311: "Tokeniser not thread-safe" + (see also Robert Marlow sbcl-help "Multi threaded read chucking a + spak" 2004-04-19) + The tokenizer's use of *read-buffer* and *read-buffer-length* causes + spurious errors should two threads attempt to tokenise at the same + time. + +312: + (reported by Jon Dyte) + SBCL issues a warning "Duplicate definition of FOO" compiling + + (declaim (inline foo)) + (defun foo (x) + (1+ x)) + (defun bar (y) + (list (foo y) (if (> y 1) (funcall (if (> y 0) #'foo #'identity) y)))) + + (probably related to the bug 280.) + +313: "source-transforms are Lisp-1" + (fixed in 0.8.10.2)