(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?)
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
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.
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
* '``(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
classes). This means that at present erroneous attempts to use
WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS
won't get the corresponding STYLE-WARNING.
- c. the examples in CLHS 7.6.5.1 (regarding generic function lambda
- lists and &KEY arguments) do not signal errors when they should.
+ c. (fixed in 0.8.4.23)
201: "Incautious type inference from compound types"
a. (reported by APD sbcl-devel 2002-09-17)
all of the arguments are circular is probably desireable).
213: "Sequence functions and type checking"
- a. MAKE-SEQUENCE, COERCE, MERGE and CONCATENATE cannot deal with
- various complicated, though recognizeable, CONS types [e.g.
- (CONS * (CONS * NULL))
- which according to ANSI should be recognized] (and, in SAFETY 3
- code, should return a list of LENGTH 2 or signal an error)
+ a. (fixed in 0.8.4.36)
b. MAP, when given a type argument that is SUBTYPEP LIST, does not
check that it will return a sequence of the given type. Fixing
it along the same lines as the others (cf. work done around
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))
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
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.
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)
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.
+
+298: (aka PFD MISC.183)
+ Compiler fails on
+
+ (defun foo ()
+ (multiple-value-call #'bar
+ (ext)
+ (catch 'tag (return-from foo (int)))))
+
+ This program violates "unknown values LVAR stack discipline": if INT
+ returns, values returned by (EXT) must be removed from under that of
+ (INT).
+
+299: (aka PFD MISC.186)
+ * (defun foo ()
+ (declare (optimize (debug 1)))
+ (multiple-value-call #'list
+ (if (eval t) (eval '(values :a :b :c)) nil) ; (*)
+ (catch 'foo (throw 'foo (values :x :y)))))
+ FOO
+ * (foo)
+ (:X :Y)
+
+ Operator THROW is represented with a call of a not returning funny
+ function %THROW, unknown values stack after the call is empty, so
+ the unknown values LVAR (*) is considered to be dead after the call
+ and, thus, before it and is popped by the stack analysis.
projects / sbcl.git / blobdiff