(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))
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
(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.
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).
-
-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.
-
+90:
+ a latent cross-compilation/bootstrapping bug: The cross-compilation
+ host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp
+ and possibly elsewhere. Instead, we should use the target system's
+ CHAR-CODE-LIMIT. This will probably cause problems if we try to
+ 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.)
+
+92:
+ (< SB-EXT:SINGLE-FLOAT-POSITIVE-INFINITY 100) signals an error:
+ error in function SB-KERNEL:INTEGER-DECODE-SINGLE-FLOAT:
+ can't decode NaN or infinity: #.EXT:SINGLE-FLOAT-POSITIVE-INFINITY
+ This is a bug in the original CMU CL code. I reported it to cmucl-imp
+ 2001-03-22 in hopes that they'll fix it for us.
+
+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.
KNOWN BUGS RELATED TO THE IR1 INTERPRETER
projects / sbcl.git / blobdiff