X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=sidebyside;f=BUGS;h=5a4d7c53c4530b88fbda3fcb95e2553cadc7ca00;hb=9d7bfe2e755ab75fa31603f1ce86d66b349bf030;hp=1b6c03909bbc389d4bf5e40b48a654d529e6a40e;hpb=f294da03824843f07d781e655d5a5e70c2c4851e;p=sbcl.git diff --git a/BUGS b/BUGS index 1b6c039..5a4d7c5 100644 --- a/BUGS +++ b/BUGS @@ -101,20 +101,6 @@ WORKAROUND: (frob-stringwise-foo *stringwise-foo*) SEGV. -6: - bogus warnings about undefined functions for magic functions like - SB!C::%%DEFUN and SB!C::%DEFCONSTANT when cross-compiling files - like src/code/float.lisp. Fixing this will probably require - straightening out enough bootstrap consistency issues that - the cross-compiler can run with *TYPE-SYSTEM-INITIALIZED*. - Instead, the cross-compiler runs in a slightly flaky state - which is sane enough to compile SBCL itself, but which is - also unstable in several ways, including its inability - to really grok function declarations. - - As of sbcl-0.7.5, sbcl's cross-compiler does run with - *TYPE-SYSTEM-INITIALIZED*; however, this bug remains. - 7: The "compiling top-level form:" output ought to be condensed. Perhaps any number of such consecutive lines ought to turn into a @@ -158,16 +144,6 @@ WORKAROUND: (FORMAT NIL "~,1G" 1.4) => "1. " (FORMAT NIL "~3,1G" 1.4) => "1. " -20: - from Marco Antoniotti on cmucl-imp mailing list 1 Mar 2000: - (defclass ccc () ()) - (setf (find-class 'ccc1) (find-class 'ccc)) - (defmethod zut ((c ccc1)) 123) - In sbcl-0.7.1.13, this gives an error, - There is no class named CCC1. - DTC's recommended workaround from the mailing list 3 Mar 2000: - (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc)) - 27: Sometimes (SB-EXT:QUIT) fails with Argh! maximum interrupt nesting depth (4096) exceeded, exiting @@ -252,8 +228,8 @@ WORKAROUND: 45: a slew of floating-point-related errors reported by Peter Van Eynde on July 25, 2000: - b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and - should probably be 1.4012985e-45. In SBCL, + b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT on the x86 is + bogus, and should probably be 1.4012985e-45. In SBCL, (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller than LEAST-POSITIVE-SHORT-FLOAT. Similar problems exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT, @@ -300,12 +276,6 @@ WORKAROUND: (ADD-METHOD (FUNCTION FOO03) M))) should give an error, but SBCL allows it. -52: - It has been reported (e.g. by Peter Van Eynde) that there are - several metaobject protocol "errors". (In order to fix them, we might - need to document exactly what metaobject protocol specification - we're following -- the current code is just inherited from PCL.) - 60: The debugger LIST-LOCATIONS command doesn't work properly. @@ -370,18 +340,6 @@ WORKAROUND: (partially alleviated in sbcl-0.7.9.32 by a fix by Matthew Danish to make the temporary filename less easily guessable) -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 - # - and - # - 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 @@ -716,6 +674,9 @@ WORKAROUND: expansion, leaving garbage consisting of infinished blocks of the partially converted function.) + (due to reordering of the compiler this example is compiled + successfully by 0.7.14, but the bug probably remains) + 162: (reported by Robert E. Brown 2002-04-16) When a function is called with too few arguments, causing the @@ -884,6 +845,28 @@ WORKAROUND: (INTEGER 1296 1296) ...)>)[:EXTERNAL] + In recent SBCL the following example also illustrates this bug: + + (time (compile + nil + '(lambda () + (declare (optimize (safety 3))) + (declare (optimize (compilation-speed 2))) + (declare (optimize (speed 1) (debug 1) (space 1))) + (let ((start 4)) + (declare (type (integer 0) start)) + (print (incf start 22)) + (print (incf start 26)) + (print (incf start 28))) + (let ((start 6)) + (declare (type (integer 0) start)) + (print (incf start 22)) + (print (incf start 26))) + (let ((start 10)) + (declare (type (integer 0) start)) + (print (incf start 22)) + (print (incf start 26)))))) + 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 @@ -1169,17 +1152,6 @@ WORKAROUND: 229: (subtypep 'function '(function)) => nil, t. -231: "SETQ does not correctly check the type of a variable being set" - b. - (defun foo (x z) - (declare (type integer x)) - (locally (declare (type (real 1) x)) - (setq x z)) - (list x z)) - (foo 0 0) => (0 0). - - (fixed in 0.7.12.8) - 233: bugs in constraint propagation a. (defun foo (x) @@ -1203,9 +1175,6 @@ WORKAROUND: (+ x 2))) (foo 1d0 5) => segmentation violation -234: - (fixed in sbcl-0.7.10.36) - 235: "type system and inline expansion" a. (declaim (ftype (function (cons) number) acc)) @@ -1273,24 +1242,19 @@ WORKAROUND: compiler gets its hands on the code needing compilation from the REPL, it has been macroexpanded several times. -240: - "confused lexical/special warnings in MULTIPLE-VALUE-BIND" - (from tonyms on #lisp IRC 2003-02-25) - In sbcl-0.7.12.55, compiling - (cl:in-package :cl-user) - (defvar *foo* 0) - (defvar *bar* 1) - (defun bar () - (multiple-value-bind (*foo* *bar*) 'eleventy-one - (bletch))) - (defun bletch () (format t "~&*FOO*=~S *BAR*=~S" *foo* *bar*)) - (bar) - gives warnings like "using the lexical binding of the symbol *FOO*" - even though LOADing the fasl file shows that in fact the special - bindings are being used. - -241: - "DEFCLASS mysteriously remembers uninterned accessor names." + A symptom of the same underlying problem, reported by Tony Martinez: + * (handler-case + (with-input-from-string (*query-io* " no") + (yes-or-no-p)) + (simple-type-error () 'error)) + ; in: LAMBDA NIL + ; (SB-KERNEL:FLOAT-WAIT) + ; + ; note: deleting unreachable code + ; compilation unit finished + ; printed 1 note + +241: "DEFCLASS mysteriously remembers uninterned accessor names." (from tonyms on #lisp IRC 2003-02-25) In sbcl-0.7.12.55, typing (defclass foo () ((bar :accessor foo-bar))) @@ -1302,6 +1266,52 @@ WORKAROUND: So it's somehow checking the uninterned old accessor name instead of the new requested accessor name, which seems broken to me (WHN). +242: "WRITE-SEQUENCE suboptimality" + (observed from clx performance) + In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type + (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) on a stream with element-type + (UNSIGNED-BYTE 8) will write to the stream one byte at a time, + rather than writing the sequence in one go, leading to severe + performance degradation. + +243: "STYLE-WARNING overenthusiasm for unused variables" + (observed from clx compilation) + In sbcl-0.7.14, in the presence of the macros + (DEFMACRO FOO (X) `(BAR ,X)) + (DEFMACRO BAR (X) (DECLARE (IGNORABLE X)) 'NIL) + somewhat surprising style warnings are emitted for + (COMPILE NIL '(LAMBDA (Y) (FOO Y))): + ; in: LAMBDA (Y) + ; (LAMBDA (Y) (FOO Y)) + ; + ; caught STYLE-WARNING: + ; The variable Y is defined but never used. + +244: "optimizing away tests for &KEY args of type declared in DEFKNOWN" + (caught by clocc-ansi-test :EXCEPSIT-LEGACY-1050) + In sbcl-0.pre8.44, (OPEN "foo" :DIRECTION :INPUT :EXTERNAL-FORMAT 'FOO) + succeeds with no error (ignoring the bogus :EXTERNAL-FORMAT argument) + apparently because the test is optimized away. The problem doesn't + exist in sbcl-0.pre8.19. Deleting the (MEMBER :DEFAULT) declaration + for :EXTERNAL-FORMAT in DEFKNOWN OPEN (and LOAD) is a workaround for + the problem (and should be removed when the problem is fixed). + +245: bugs in disassembler + a. On X86 an immediate operand for IMUL is printed incorrectly. + b. On X86 operand size prefix is not recognized. + +246: "NTH-VALUE scaling problem" + NTH-VALUE's current implementation for constant integers scales in + compile-time as O(n^4), as indeed must the optional dispatch + mechanism on which it is implemented. While it is unlikely to + matter in real user code, it's still unpleasant to observe that + (NTH-VALUE 1000 (VALUES-LIST (MAKE-LIST 1001))) takes several hours + to compile. + +248: "reporting errors in type specifier syntax" + (TYPEP 1 '(SYMBOL NIL)) says something about "unknown type + specifier". + DEFUNCT CATEGORIES OF BUGS IR1-#: These labels were used for bugs related to the old IR1 interpreter.