|
Apparent CMU CL compiler bug: msg#00293lisp.cmucl.devel
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> |
|---|---|---|
| Previous by Date: | Re: HEADSUP: Generational GC for Sparc: 00293, Raymond Toy |
|---|---|
| Next by Date: | Re: Apparent CMU CL compiler bug: 00293, Raymond Toy |
| Previous by Thread: | Fix for CLX display host problemi: 00293, Fred Gilham |
| Next by Thread: | Re: Apparent CMU CL compiler bug: 00293, Raymond Toy |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |