The following function causes the compiler to hiccup.
(defun zz5 ()
(LET ((X (THE SYMBOL 'A)))
(DECLARE (TYPE (OR FIXNUM SYMBOL) X))
(PROGN
(THE FIXNUM
(COND
(TYPE-OF-X-CAN-CHANGE*
(THE FIXNUM
(LET* ()
(LET ((#:G1688 4))
(SETQ X #:G1688)))))
(T (print 'no-change))))
(COND ((integerp X) (= X 5)) (T (EQ X (THE SYMBOL 'A)))))))
The function looks a bit funny because it's the output of a macro.
I've cleaned it up a bit so just the essential problem is emphasized.
The function is buggy because the declaration "(THE FIXNUM ...)" is
wrong.
I'm running CMUCL version 19a --
CMU Common Lisp 19a, running on zebra
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Wed, 2004-07-28 12:51:48-04:00 on lorien
under SLIME.
Compiling ZZ5 causes the compiler to abort, producing the following
in the SLIME repl --
CL-USER> (compile 'zz5)
; Compiling LAMBDA NIL:
; In: LAMBDA NIL
; (LET (#)
; (SETQ X #:G1688))
; Note: Variable #:G1688 defined but never used.
;
; (PRINT 'NO-CHANGE)
; Warning: Result is a (MEMBER NO-CHANGE), not a (VALUES FIXNUM &REST T).
;
The abort occurs because I typed "q" to the SLIME debugger, whose
output is shown below.
; Evaluation aborted
; Compilation unit aborted.
; 1 warning
; 1 note
CL-USER>
The SLIME debugger buffer gives a bit more information:
Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: NIL is not of type C::NODE
[Condition of type TYPE-ERROR]
Restarts:
0: [ABORT] Abort handling SLIME request.
1: [ABORT] Return to Top-Level.
Backtrace:
0: (C::GENERATE-TYPE-CHECKS #<C:COMPONENT 589EA885 NAME= "LAMBDA NIL" REANALYZE=
T>)
1: (C::IR1-PHASES #<C:COMPONENT 589EA885 NAME= "LAMBDA NIL" REANALYZE= T>)
2: (C::COMPILE-COMPONENT #<C:COMPONENT 589EA885 NAME= "LAMBDA NIL" REANALYZE= T>)
3: ((FLET #:G0 COMPILE))
4: (COMPILE ZZ5 #<Interpreted Function ZZ5 {589AB539}>)
5: (COMPILE 1 ZZ5 #<Unknown Immediate Object, lowtag=#b110, type=#xEE
{1007B7EE}>)[:EXTERNAL]
6: (SWANK::EVAL-REGION "(compile 'zz5)
" T)
7: ("DEFSLIMEFUN LISTENER-EVAL")
8: (SWANK:LISTENER-EVAL "(compile 'zz5)
")
9: (SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(compile 'zz5)
") "COMMON-LISP-USER" 137)
10: ("DEFUN HANDLE-REQUEST")
11: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {5865AC35}> #<Function
"DEFUN HANDLE-REQUEST" {58512919}>)
12: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {5865AC35}>)
13: (SWANK::PROCESS-AVAILABLE-INPUT #<Stream for descriptor 6> #<Closure Over
Function "DEFUN INSTALL-SIGIO-HANDLER" {589E1671}>)
14: ((FLET SWANK::HANDLER SWANK::INSTALL-SIGIO-HANDLER))
15: (SWANK-BACKEND::SIGIO-HANDLER #<#1=unused-arg> #<#1#> #<#1#>)
16: ("call_into_lisp+#x8C [#x80546CC] /usr/local/bin/cmucl")
17: ("funcall3+#x29 [#x80544DC] /usr/local/bin/cmucl")
18: ("interrupt_handle_now+#xEE [#x80501CF] /usr/local/bin/cmucl")
19: ("NIL+#x80505EF [#x80505EF] /usr/local/bin/cmucl")
20: ("Foreign function call land")
21: (SYSTEM:WAIT-UNTIL-FD-USABLE 0 :INPUT NIL)
22: (LISP::DO-INPUT #<Stream for Standard Input>)
23: (LISP::INPUT-CHARACTER #<Stream for Standard Input> NIL (LISP::*EOF*))
24: (LISP::SYNONYM-IN #<Synonym Stream to SYSTEM:*STDIN*> NIL (LISP::*EOF*))
25: (LISP::TWO-WAY-IN #<Two-Way Stream, Input = #<Synonym Stream to
SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (LISP::*EOF*))
26: (LISP::SYNONYM-IN #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL
(LISP::*EOF*))
27: (READ-CHAR #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL
(LISP::*EOF*) NIL)
28: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL #<Synonym Stream to
SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) T)
29: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL #<Synonym Stream to
SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) NIL)
30: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL 4 #<Synonym Stream to
SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) ...)[:EXTERNAL]
31: (LISP::READ-INTERNAL #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL
(:EOF) NIL)
32: (READ #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) NIL)
33: (LISP::%TOP-LEVEL)
34: ((LABELS LISP::RESTART-LISP SAVE-LISP))
The compiler is correctly inferring that the declaration is wrong, but
it obviously shouldn't then self-destruct.
This probably is not an urgent bug fix, given that fixing the
declaration makes the problem go away.
-- Drew
