logo       

Apparent CMU CL compiler bug: msg#00293

lisp.cmucl.devel

Subject: Apparent CMU CL compiler bug

I apologize for the vague subject line; I'm not familiar enough
with the compiler's internals to isolate one line's worth of
useful information.

I've been playing with evolutionary programming, which is a
great source of somewhat random code to feed to the compiler.
If this is indeed a compiler bug, then it's the second I've
found in this way! Here, first of all, are some details of
my system.

Hardware: ia32 (Athlon)
OS: FreeBSD 4.something
CMU CL: version 18d, compiled using FreeBSD port

This machine has never, so far as I know, suffered anything
that looked much like hardware trouble, which is why I'm
tentatively choosing to blame CMU CL rather than the hardware.

Here's what I believe to be the relevant portion of the
backtrace. (After that it goes into my own code.)

Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
536870911 is not of type (MOD 536870911)

Restarts:
0: [ABORT] Return to Top-Level.

Debug (type H for help)

(C::VOLATILE-INFO-LOOKUP 3
#<C::VOLATILE-INFO-ENV "Working">
#:INDEX-0
536870911)[:EXTERNAL]
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists:
target:compiler/globaldb.lisp.
0] backtrace
0: (C::VOLATILE-INFO-LOOKUP 3
#<C::VOLATILE-INFO-ENV "Working">
#:INDEX-0
536870911)[:EXTERNAL]
1: (C::LOOKUP-IGNORING-GLOBAL-CACHE
(#<C::VOLATILE-INFO-ENV "Working"> #<C::COMPACT-INFO-ENV "Auxiliary">
#<C::COMPACT-INFO-ENV "X86 backend"> #<C::COMPACT-INFO-ENV "Compiler">
#<C::COMPACT-INFO-ENV "Kernel">))
2: (C::GET-INFO-VALUE #:INDEX-0 14 NIL)
3: (C::GET-INFO-VALUE 2 #:INDEX-0 14 301989455)[:EXTERNAL]
4: (C::VARIFY-LAMBDA-ARG #:INDEX-0 (ARRAY))
5: (C::IR1-CONVERT-LAMBDA
(LAMBDA (ARRAY #:INDEX-0)
(LET* #
#))
NIL
NIL)
6: (C::IR1-CONVERT-INLINE-LAMBDA
(LAMBDA (ARRAY #:INDEX-0)
(LET* #
#))
NIL
NIL)
7: (C::TRANSFORM-CALL
#<C::COMBINATION #x48C91F45
FUN= #<C::REF #x48C91F15 LEAF= #<C::GLOBAL-VAR 48C8315D>>
ARGS= (#<C::REF 48C91FBD> #<C::REF 48CC6045>)>
(LAMBDA (ARRAY #:INDEX-0)
(LET* #
#)))
8: (C::IR1-OPTIMIZE-COMBINATION
#<C::COMBINATION #x48C91F45
FUN= #<C::REF #x48C91F15 LEAF= #<C::GLOBAL-VAR 48C8315D>>
ARGS= (#<C::REF 48C91FBD> #<C::REF 48CC6045>)>)
9: (C::IR1-OPTIMIZE
#<C:COMPONENT #x48CCBF1D NAME= "LAMBDA (COUPLINGS)" REANALYZE= T>)
10: (C::IR1-OPTIMIZE-UNTIL-DONE
#<C:COMPONENT #x48CCBF1D NAME= "LAMBDA (COUPLINGS)" REANALYZE= T>)
11: (C::IR1-PHASES
#<C:COMPONENT #x48CCBF1D NAME= "LAMBDA (COUPLINGS)" REANALYZE= T>)
12: (C::COMPILE-COMPONENT
#<C:COMPONENT #x48CCBF1D NAME= "LAMBDA (COUPLINGS)" REANALYZE= T>)
13: (#:G0)
14: (COMPILE NIL
(LAMBDA (COUPLINGS)
(DECLARE # # # #)
(* -0.28157314694834445d0 # #)))
15: (COMPILE 2
NIL
(LAMBDA (COUPLINGS)
(DECLARE # # # #)
(* -0.28157314694834445d0 # #)))[:EXTERNAL]

And, since the forms hidden by those hashes are potentially
relevant:

15] pp
(COMPILE 2
NIL
(LAMBDA (COUPLINGS)
(DECLARE (IGNORABLE COUPLINGS)
(TYPE (ARRAY DOUBLE-FLOAT (3)) COUPLINGS)
(VALUES DOUBLE-FLOAT)
(OPTIMIZE (INHIBIT-WARNINGS 3)))
(* -0.28157314694834445d0
(+ (AREF COUPLINGS 1)
(* (AREF COUPLINGS 0)
1.6423813483707832d0
-0.28157314694834445d0
(+ (AREF COUPLINGS 0)
(* 1.6423813483707832d0 (AREF COUPLINGS 1))
(* (AREF COUPLINGS 0)
-3.970822355081399d0
-3.970822355081399d0))
-0.28157314694834445d0
(+
(* (AREF COUPLINGS 2)
-4.2575969041029795d0
(SQUARE
(* (AREF COUPLINGS 2)
(+ (AREF COUPLINGS 0)
(AREF COUPLINGS 1)
(AREF COUPLINGS 0))))
(AREF COUPLINGS 2)
(AREF COUPLINGS 1))
(AREF COUPLINGS 1)
-0.01036753259739509d0
(AREF COUPLINGS 1))
(AREF COUPLINGS 2))
(ATAN (AREF COUPLINGS 1)
(*
(+
(* 3.5783156939259086d0
(+
(* 1.9322815947063288d0
3.5783156939259086d0
(AREF COUPLINGS 0))
(AREF COUPLINGS 0)
(AREF COUPLINGS 1))
(AREF COUPLINGS 0))
(*
(- (AREF COUPLINGS 1)
(SQUARE
(+ (AREF COUPLINGS 1)
(* (AREF COUPLINGS 0)
1.6393626534254047d0
-0.28157314694834445d0
(+ -0.28157314694834445d0
(* 1.6423813483707832d0
(AREF COUPLINGS 1))
(* (AREF COUPLINGS 0)
-3.9117058898882657d0
-3.970822355081399d0))
-0.28157314694834445d0
(+
(* (AREF COUPLINGS 2)
-3.970822355081399d0
(SQUARE
(* (AREF COUPLINGS 2)
(+ (AREF COUPLINGS 0)
(AREF COUPLINGS 1)
(AREF COUPLINGS 0))))
(AREF COUPLINGS 2)
(AREF COUPLINGS 1))
(AREF COUPLINGS 1)
0.13694895531853568d0
(AREF COUPLINGS 1))
(AREF COUPLINGS 2))
(ATAN (AREF COUPLINGS 1)
(*
(+
(* 3.5783156939259086d0
(+
(* 1.9322815947063288d0
3.5783156939259086d0
(AREF COUPLINGS 0))
(AREF COUPLINGS 0)
(AREF COUPLINGS 1))
(AREF COUPLINGS 0))
(*
(- (AREF COUPLINGS 0)
(SQUARE
(SQUARE
(* -1.64550538436169d0
(AREF COUPLINGS 1)))))
-0.01036753259739509d0
(AREF COUPLINGS 2))
-1.5139755729694455d0
(* (AREF COUPLINGS 2)
1.572745982753589d0
(AREF COUPLINGS 2)))
-0.6064861619825485d0))
(AREF COUPLINGS 0))))
-0.01036753259739509d0
(AREF COUPLINGS 2))
-1.5139755729694455d0
(* (AREF COUPLINGS 2)
1.572745982753589d0
(AREF COUPLINGS 2)))
-0.6064861619825485d0))
(AREF COUPLINGS 0))
(AREF COUPLINGS 2))))[:EXTERNAL]

If I start up a fresh Lisp instance on the same machine and do
(COMPILE NIL <stuff>), where <stuff> is the big complicated argument
above, it apparently compiles smoothly. This is not good news :-).

I have the offending Lisp process sat at a debugger prompt.
If there's anything I can usefully do with it, do let me know.

--
g






<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise