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 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,
- and LEAST-NEGATIVE-LONG-FLOAT.
c: Many expressions generate floating infinity on x86/Linux:
(/ 1 0.0)
(/ 1 0.0d0)
crashes SBCL. In general tracing anything which is used in the
implementation of TRACE is likely to have the same problem.
-75:
- As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000,
- ANSI says that WITH-OUTPUT-TO-STRING should have a keyword
- :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for
- WITH-OUTPUT-TO-STRING.
-
78:
ANSI says in one place that type declarations can be abbreviated even
when the type name is not a symbol, e.g.
holding... * is not equivalent to T in many cases, such as
(VECTOR *) /= (VECTOR T).
-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
Then (FOO #\1 *STANDARD-OUTPUT*) signals type error.
(In 0.7.9.1 the result type is (FUNCTION * *), so Python does not
- produce invalid code, but type checking is not accurate. Similar
- problems exist with VALUES-TYPE-INTERSECTION.)
-
-220:
- Sbcl 0.7.9 fails to compile
-
- (multiple-value-call #'list
- (the integer (helper))
- nil)
-
- Type check for INTEGER, the result of which serves as the first
- argument of M-V-C, is inserted after evaluation of NIL. So arguments
- of M-V-C are pushed in the wrong order. As a temporary workaround
- type checking was disabled for M-V-Cs in 0.7.9.13. A better solution
- would be to put the check between evaluation of arguments, but it
- could be tricky to check result types of PROG1, IF etc.
+ produce invalid code, but type checking is not accurate.)
233: bugs in constraint propagation
a.
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
+ looks reasonable, if not obviously correct; however, it caused the
+ PPC/Linux port to segfault during warm-init while loading
+ src/pcl/std-class.fasl. A workaround patch was made, but it would
+ be nice to understand why the first patch caused problems, and to
+ fix the cause if possible.
+
+268: "wrong free declaration scope"
+ The following code must signal type error:
+
+ (locally (declare (optimize (safety 3)))
+ (flet ((foo (x &optional (y (car x)))
+ (declare (optimize (safety 0)))
+ (list x y)))
+ (funcall (eval #'foo) 1)))
+
+269:
+ SCALE-FLOAT should accept any integer for its second argument.
+
+270:
+ In the following function constraint propagator optimizes nothing:
+
+ (defun foo (x)
+ (declare (integer x))
+ (declare (optimize speed))
+ (typecase x
+ (fixnum "hala")
+ (fixnum "buba")
+ (bignum "hip")
+ (t "zuz")))
+
+272:
+ All forms of GC hooks (including notifiers and finalisers) are currently
+ (since 0.8.0) broken for gencgc (i.e. x86) users
+
+273:
+ Compilation of the following two forms causes "X is unbound" error:
+
+ (symbol-macrolet ((x pi))
+ (macrolet ((foo (y) (+ x y)))
+ (declaim (inline bar))
+ (defun bar (z)
+ (* z (foo 4)))))
+ (defun quux (z)
+ (bar z))
+
+ (See (COERCE (CDR X) 'FUNCTION) in IR1-CONVERT-INLINE-LAMBDA.)
+
+274:
+ CLHS says that type declaration of a symbol macro should not affect
+ its expansion, but in SBCL it does.
+
+275:
+ The following code (taken from CLOCC) takes a lot of time to compile:
+
+ (defun foo (n)
+ (declare (type (integer 0 #.large-constant) n))
+ (expt 1/10 n))
+
+ (fixed in 0.8.2.51, but a test case would be good)
+
+276:
+ (defmethod fee ((x fixnum))
+ (setq x (/ x 2))
+ x)
+ (fee 1) => type error
+
+ (taken from CLOCC)
+
+
DEFUNCT CATEGORIES OF BUGS
IR1-#:
These labels were used for bugs related to the old IR1 interpreter.