an error may be signalled at read time and it would be good if
SBCL did it.
- c: Reading of not initialized slot sometimes causes SEGV (for inline
- accessors it is fixed, but out-of-line still do not perform type
- check).
-
- d:
- (declaim (optimize (safety 3) (speed 1) (space 1)))
- (defstruct foo
- x y)
- (defstruct (stringwise-foo (:include foo
- (x "x" :type simple-string)
- (y "y" :type simple-string))))
- (defparameter *stringwise-foo*
- (make-stringwise-foo))
- (setf (foo-x *stringwise-foo*) 0)
- (defun frob-stringwise-foo (sf)
- (aref (stringwise-foo-x sf) 0))
- (frob-stringwise-foo *stringwise-foo*)
- SEGV.
+ d: (fixed in 0.8.1.5)
7:
The "compiling top-level form:" output ought to be condensed.
Perhaps any number of such consecutive lines ought to turn into a
single "compiling top-level forms:" line.
-10:
- The way that the compiler munges types with arguments together
- with types with no arguments (in e.g. TYPE-EXPAND) leads to
- weirdness visible to the user:
- (DEFTYPE FOO () 'FIXNUM)
- (TYPEP 11 'FOO) => T
- (TYPEP 11 '(FOO)) => T, which seems weird
- (TYPEP 11 'FIXNUM) => T
- (TYPEP 11 '(FIXNUM)) signals an error, as it should
- The situation is complicated by the presence of Common Lisp types
- like UNSIGNED-BYTE (which can either be used in list form or alone)
- so I'm not 100% sure that the behavior above is actually illegal.
- But I'm 90+% sure, and the following related behavior,
- (TYPEP 11 'AND) => T
- treating the bare symbol AND as equivalent to '(AND), is specifically
- forbidden (by the ANSI specification of the AND type).
-
11:
It would be nice if the
caught ERROR:
(during macroexpansion of IN-PACKAGE,
during macroexpansion of DEFFOO)
-15:
- (SUBTYPEP '(FUNCTION (T BOOLEAN) NIL)
- '(FUNCTION (FIXNUM FIXNUM) NIL)) => T, T
- (Also, when this is fixed, we can enable the code in PROCLAIM which
- checks for incompatible FTYPE redeclarations.)
-
19:
(I *think* this is a bug. It certainly seems like strange behavior. But
the ANSI spec is scary, dark, and deep.. -- WHN)
so they could be supported after all. Very likely
SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
-43:
- (as discussed by Douglas Crosher on the cmucl-imp mailing list ca.
- Aug. 10, 2000): CMUCL currently interprets 'member as '(member); same
- issue with 'union, 'and, 'or etc. So even though according to the
- ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL
- (and now SBCL) interpret them as legal types.
-
45:
a slew of floating-point-related errors reported by Peter Van Eynde
on July 25, 2000:
46:
type safety errors reported by Peter Van Eynde July 25, 2000:
- c: (COERCE 'AND 'FUNCTION) returns something related to
- (MACRO-FUNCTION 'AND), but ANSI says it should raise an error.
k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is
not a binary input stream, but instead cheerfully reads from
character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
60:
The debugger LIST-LOCATIONS command doesn't work properly.
+ (How should it work properly?)
61:
Compiling and loading
then requesting a BACKTRACE at the debugger prompt gives no information
about where in the user program the problem occurred.
-63:
- Paul Werkowski wrote on cmucl-imp@cons.org 2000-11-15
- I am looking into this problem that showed up on the cmucl-help
- list. It seems to me that the "implementation specific environment
- hacking functions" found in pcl/walker.lisp are completely messed
- up. The good thing is that they appear to be barely used within
- PCL and the munged environment object is passed to cmucl only
- in calls to macroexpand-1, which is probably why this case fails.
- SBCL uses essentially the same code, so if the environment hacking
- is screwed up, it affects us too.
-
64:
Using the pretty-printer from the command prompt gives funny
results, apparently because the pretty-printer doesn't know
so the compiler doesn't compile the type test into code, but
instead just saves the type in a lexical closure and interprets it
at runtime.
- A proper solution involves deciding whether it's really worth
- saving space by implementing structure slot accessors as closures.
- (If it's not worth it, the problem vanishes automatically. If it
- is worth it, there are hacks we could use to force type tests to
- be compiled anyway, and even shared. E.g. we could implement
- an EQUAL hash table mapping from types to compiled type tests,
- and save the appropriate compiled type test as part of each lexical
- closure; or we could make the lexical closures be placeholders
- which overwrite their old definition as a lexical closure with
- a new compiled definition the first time that they're called.)
- As a workaround for the problem, #'(SETF FOO) expressions can
- be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
+ To exercise the problem, compile and load
+ (cl:in-package :cl-user)
+ (defstruct foo
+ (bar (error "missing") :type bar))
+ (defvar *foo*)
+ (defun wastrel1 (x)
+ (loop (setf (foo-bar *foo*) x)))
+ (defstruct bar)
+ (defvar *bar* (make-bar))
+ (defvar *foo* (make-foo :bar *bar*))
+ (defvar *setf-foo-bar* #'(setf foo-bar))
+ (defun wastrel2 (x)
+ (loop (funcall *setf-foo-bar* x *foo*)))
+ then run (WASTREL1 *BAR*) or (WASTREL2 *BAR*), hit Ctrl-C, and
+ use BACKTRACE, to see it's spending all essentially all its time
+ in %TYPEP and VALUES-SPECIFIER-TYPE and so forth.
+ One possible solution would be simply to give up on
+ representing structure slot accessors as functions, and represent
+ them as macroexpansions instead. This can be inconvenient for users,
+ but it's not clear that it's worse than trying to help by expanding
+ into a horribly inefficient implementation.
+ As a workaround for the problem, #'(SETF FOO) expressions
+ can be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
(defmacro efficient-setf-function (place-function-name)
- (or #+sbcl (and (sb-impl::info :function :accessor-for place-function-name)
+ (or #+sbcl (and (sb-int:info :function :accessor-for place-function-name)
;; a workaround for the problem, encouraging the
;; inline expansion of the structure accessor, so
;; that the compiler can optimize its type test
under OpenBSD 2.9 on my X86 laptop. Do be patient when you try it:
it took more than two minutes (but less than five) for me.
-144:
- (This was once known as IR1-4, but it lived on even after the
- IR1 interpreter went to the big bit bucket in the sky.)
- The system accepts DECLAIM in most places where DECLARE would be
- accepted, without even issuing a warning. ANSI allows this, but since
- it's fairly easy to mistype DECLAIM instead of DECLARE, and the
- meaning is rather different, and it's unlikely that the user
- has a good reason for doing DECLAIM not at top level, it would be
- good to issue a STYLE-WARNING when this happens. A possible
- fix would be to issue STYLE-WARNINGs for DECLAIMs not at top level,
- or perhaps to issue STYLE-WARNINGs for any EVAL-WHEN not at top level.
- [This is considered an IR1-interpreter-related bug because until
- EVAL-WHEN is rewritten, which won't happen until after the IR1
- interpreter is gone, the system's notion of what's a top-level form
- and what's not will remain too confused to fix this problem.]
-
145:
ANSI allows types `(COMPLEX ,FOO) to use very hairy values for
FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL
See also bugs #45.c and #183
-148:
- In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file
- (in-package :cl-user)
- (defvar *thing*)
- (defvar *zoom*)
- (defstruct foo bar bletch)
- (defun %zeep ()
- (labels ((kidify1 (kid)
- )
- (kid-frob (kid)
- (if *thing*
- (setf sweptm
- (m+ (frobnicate kid)
- sweptm))
- (kidify1 kid))))
- (declare (inline kid-frob))
- (map nil
- #'kid-frob
- (the simple-vector (foo-bar perd)))))
- fails with
- debugger invoked on condition of type TYPE-ERROR:
- The value NIL is not of type SB-C::NODE.
- The location of this failure has moved around as various related
- issues were cleaned up. As of sbcl-0.7.1.9, it occurs in
- NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
-
- (Python LET-converts KIDIFY1 into KID-FROB, then tries to inline
- expand KID-FROB into %ZEEP. Having partially done it, it sees a call
- of KIDIFY1, which already does not exist. So it gives up on
- 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
:ACCRUED-EXCEPTIONS (:INEXACT)
:FAST-MODE NIL)
-187: "type inference confusion around DEFTRANSFORM time"
- (reported even more verbosely on sbcl-devel 2002-06-28 as "strange
- bug in DEFTRANSFORM")
- After the file below is compiled and loaded in sbcl-0.7.5, executing
- (TCX (MAKE-ARRAY 4 :FILL-POINTER 2) 0)
- at the REPL returns an adjustable vector, which is wrong. Presumably
- somehow the DERIVE-TYPE information for the output values of %WAD is
- being mispropagated as a type constraint on the input values of %WAD,
- and so causing the type test to be optimized away. It's unclear how
- hand-expanding the DEFTRANSFORM would change this, but it suggests
- the DEFTRANSFORM machinery (or at least the way DEFTRANSFORMs are
- invoked at a particular phase) is involved.
- (cl:in-package :sb-c)
- (eval-when (:compile-toplevel)
- ;;; standin for %DATA-VECTOR-AND-INDEX
- (defknown %dvai (array index)
- (values t t)
- (foldable flushable))
- (deftransform %dvai ((array index)
- (vector t)
- *
- :important t)
- (let* ((atype (continuation-type array))
- (eltype (array-type-specialized-element-type atype)))
- (when (eq eltype *wild-type*)
- (give-up-ir1-transform
- "specialized array element type not known at compile-time"))
- (when (not (array-type-complexp atype))
- (give-up-ir1-transform "SIMPLE array!"))
- `(if (array-header-p array)
- (%wad array index nil)
- (values array index))))
- ;;; standin for %WITH-ARRAY-DATA
- (defknown %wad (array index (or index null))
- (values (simple-array * (*)) index index index)
- (foldable flushable))
- ;;; (Commenting out this optimizer causes the bug to go away.)
- (defoptimizer (%wad derive-type) ((array start end))
- (let ((atype (continuation-type array)))
- (when (array-type-p atype)
- (values-specifier-type
- `(values (simple-array ,(type-specifier
- (array-type-specialized-element-type atype))
- (*))
- index index index)))))
- ) ; EVAL-WHEN
- (defun %wad (array start end)
- (format t "~&in %WAD~%")
- (%with-array-data array start end))
- (cl:in-package :cl-user)
- (defun tcx (v i)
- (declare (type (vector t) v))
- (declare (notinline sb-kernel::%with-array-data))
- ;; (Hand-expending DEFTRANSFORM %DVAI here also causes the bug to
- ;; go away.)
- (sb-c::%dvai v i))
-
188: "compiler performance fiasco involving type inference and UNION-TYPE"
- (In sbcl-0.7.6.10, DEFTRANSFORM CONCATENATE was commented out until this
- bug could be fixed properly, so you won't see the bug unless you restore
- the DEFTRANSFORM by hand.) In sbcl-0.7.5.11 on a 700 MHz Pentium III,
- (time (compile
- nil
- '(lambda ()
- (declare (optimize (safety 3)))
- (declare (optimize (compilation-speed 2)))
- (declare (optimize (speed 1) (debug 1) (space 1)))
- (let ((fn "if-this-file-exists-the-universe-is-strange"))
- (load fn :if-does-not-exist nil)
- (load (concatenate 'string fn ".lisp") :if-does-not-exist nil)
- (load (concatenate 'string fn ".fasl") :if-does-not-exist nil)
- (load (concatenate 'string fn ".misc-garbage")
- :if-does-not-exist nil)))))
- reports
- 134.552 seconds of real time
- 133.35156 seconds of user run time
- 0.03125 seconds of system run time
- [Run times include 2.787 seconds GC run time.]
- 0 page faults and
- 246883368 bytes consed.
- BACKTRACE from Ctrl-C in the compilation shows that the compiler is
- thinking about type relationships involving types like
- #<UNION-TYPE
- (OR (INTEGER 576 576)
- (INTEGER 1192 1192)
- (INTEGER 2536 2536)
- (INTEGER 1816 1816)
- (INTEGER 2752 2752)
- (INTEGER 1600 1600)
- (INTEGER 2640 2640)
- (INTEGER 1808 1808)
- (INTEGER 1296 1296)
- ...)>)[:EXTERNAL]
-
- In recent SBCL the following example also illustrates this bug:
-
(time (compile
nil
'(lambda ()
(print (incf start 22))
(print (incf start 26))))))
+ This example could be solved with clever enough constraint
+ propagation or with SSA, but consider
+
+ (let ((x 0))
+ (loop (incf x 2)))
+
+ The careful type of X is {2k} :-(. Is it really important to be
+ able to work with unions of many intervals?
+
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
c. the examples in CLHS 7.6.5.1 (regarding generic function lambda
lists and &KEY arguments) do not signal errors when they should.
-
-201: "Incautious type inference from compound CONS types"
- (reported by APD sbcl-devel 2002-09-17)
+201: "Incautious type inference from compound types"
+ a. (reported by APD sbcl-devel 2002-09-17)
(DEFUN FOO (X)
(LET ((Y (CAR (THE (CONS INTEGER *) X))))
(SETF (CAR X) NIL)
(FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"
+ b.
+ * (defun foo (x)
+ (declare (type (array * (4 4)) x))
+ (let ((y x))
+ (setq x (make-array '(4 4)))
+ (adjust-array y '(3 5))
+ (= (array-dimension y 0) (eval `(array-dimension ,y 0)))))
+ FOO
+ * (foo (make-array '(4 4) :adjustable t))
+ NIL
+
205: "environment issues in cross compiler"
(These bugs have no impact on user code, but should be fixed or
documented.)
(foo '(nil) '(t)) => NIL, T.
- b. (reported by brown on #lisp 2003-01-21)
-
- (defun find-it (x)
- (declare (optimize (speed 3) (safety 0)))
- (declare (notinline mapcar))
- (let ((z (mapcar #'car x)))
- (find 'foobar z)))
-
- Without (DECLARE (NOTINLINE MAPCAR)), Python cannot derive that Z is
- LIST.
-
237: "Environment arguments to type functions"
a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
UPGRADED-COMPLEX-PART-TYPE now have an optional environment
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".
does not cause a warning. (BTW: old SBCL issued a warning, but for a
function, which was never called!)
+256:
+ Compiler does not emit warnings for
+
+ a. (lambda () (svref (make-array 8 :adjustable t) 1))
+
+ b. (lambda (x)
+ (list (let ((y (the real x)))
+ (unless (floatp y) (error ""))
+ y)
+ (integer-length x)))
+
+ c. (lambda (x)
+ (declare (optimize (debug 0)))
+ (declare (type vector x))
+ (list (fill-pointer x)
+ (svref x 1)))
+
+257:
+ Complex array type does not have corresponding type specifier.
+
+ This is a problem because the compiler emits optimization notes when
+ you use a non-simple array, and without a type specifier for hairy
+ array types, there's no good way to tell it you're doing it
+ intentionally so that it should shut up and just compile the code.
+
+ Another problem is confusing error message "asserted type ARRAY
+ conflicts with derived type (VALUES SIMPLE-VECTOR &OPTIONAL)" during
+ compiling (LAMBDA (V) (VALUES (SVREF V 0) (VECTOR-POP V))).
+
+ The last problem is that when type assertions are converted to type
+ checks, types are represented with type specifiers, so we could lose
+ complex attribute. (Now this is probably not important, because
+ currently checks for complex arrays seem to be performed by
+ callees.)
+
+258:
+ (fixed in 0.8.1.3)
+
+259:
+ (compile nil '(lambda () (aref (make-array 0) 0))) compiles without
+ warning. Analogous cases with the index and length being equal and
+ greater than 0 are warned for; the problem here seems to be that the
+ type required for an array reference of this type is (INTEGER 0 (0))
+ which is canonicalized to NIL.
+
DEFUNCT CATEGORIES OF BUGS
IR1-#:
These labels were used for bugs related to the old IR1 interpreter.