X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=ad30c7b996929c947c9d2499e7cb51ec7b791be7;hb=a18f0a95bc9a457e4d2d00c702b746f29c2662b1;hp=5e56ae9d37f2948db01a568ccc39e16e723f13cb;hpb=143edab8d233c784cde14bce6c5165219ea84bf4;p=sbcl.git diff --git a/BUGS b/BUGS index 5e56ae9..ad30c7b 100644 --- a/BUGS +++ b/BUGS @@ -118,15 +118,6 @@ WORKAROUND: (during macroexpansion of IN-PACKAGE, during macroexpansion of DEFFOO) -13: - Floating point infinities are screwed up. [When I was converting CMU CL - to SBCL, I was looking for complexity to delete, and I thought it was safe - to just delete support for floating point infinities. It wasn't: they're - generated by the floating point hardware even when we remove support - for them in software. Also we claim the :IEEE-FLOATING-POINT feature, - and I think that means we should support infinities.-- WHN] Support - for them should be restored. - 14: The ANSI syntax for non-STANDARD method combination types in CLOS is (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN)) @@ -234,10 +225,12 @@ WORKAROUND: 26: reported by Sam Steingold on the cmucl-imp mailing list 12 May 2000: - -Also, there is another bug: `array-displacement' should return an array -or nil as first value (as per ANSI CL), while CMUCL declares it as -returning an array as first value always. + Also, there is another bug: `array-displacement' should return an + array or nil as first value (as per ANSI CL), while CMUCL declares + it as returning an array as first value always. + (Actually, I think the old CMU CL version in SBCL never returns NIL, + i.e. it's not just a declaration problem, but the definition doesn't + behave ANSIly.) 27: Sometimes (SB-EXT:QUIT) fails with @@ -365,9 +358,7 @@ returning an array as first value always. 45: a slew of floating-point-related errors reported by Peter Van Eynde on July 25, 2000: - a: (SQRT -9.0) fails, because SB-KERNEL::COMPLEX-SQRT is undefined. - Similarly, COMPLEX-ASIN, COMPLEX-ACOS, COMPLEX-ACOSH, and others - aren't found. + a: (fixed in sbcl-0.6.11.25) b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and should probably be 1.4012985e-45. In SBCL, (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller @@ -381,10 +372,7 @@ returning an array as first value always. (EXPT 10.0d0 1000) PVE's regression tests want them to raise errors. SBCL generates the infinities instead, which may or may not be - conforming behavior, but then blow it by being unable to - output the infinities, since support for infinities is generally - broken, and in particular SB-IMPL::OUTPUT-FLOAT-INFINITY is - undefined. + conforming behavior. d: (in section12.erg) various forms a la (FLOAT 1 DOUBLE-FLOAT-EPSILON) don't give the right behavior. @@ -825,25 +813,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: (I haven't tried to investigate this bug enough to guess whether there might be any user-level symptoms.) -87: - Despite what the manual says, (DECLAIM (SPEED 0)) doesn't cause - things to be byte compiled. This seems to be true in cmucl-2.4.19, - too: (COMPILE-FILE .. :BYTE-COMPILE T) causes byte-compilation, - but ordinary COMPILE-FILE of a file containing (DECLAIM (SPEED 0)) - does not. - -88: - The type system doesn't understand that the intersection of the - types (MEMBER :FOO) and (OR KEYWORD NULL) is (MEMBER :FOO). Thus, - the optimizer can't make some useful valid type inferences. - -89: - The type system doesn't understand the the intersection of the types - KEYWORD and (OR KEYWORD NULL) is KEYWORD, perhaps because KEYWORD - is itself an intersection type and that causes technical problems - with the simplification. Thus, the optimizer can't make some useful - valid type inferences. - 90: a latent cross-compilation/bootstrapping bug: The cross-compilation host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp @@ -852,6 +821,87 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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 wasn incompletely implemented + in the X86 port of CMU CL, and we haven't fixed it in SBCL. + +97: + FRESH-LINE doesn't seem to work properly within pretty-printed + output. E.g. + "~@~2%" + called on a CONDITION whose printer does + "~&~@" + gives two newlines between "unhandled CONDITION" and "error", when + (it at least seems as though) correct behavior would be to give one. + KNOWN BUGS RELATED TO THE IR1 INTERPRETER