Hi, Alesio
Oh, sorry, maybe I didn't say it clearly, the "Register 4 contains wrong type" is not produced by the file with THREADS:WITH-MUTEX. It's another issue, not relevant to the first post in this mail thread.
Following function caused the "Register 4 contains wrong type" issue:
(defun generate-table (vars vbs non-repeaters max-repetitions) (declare (type fixnum non-repeaters max-repetitions)) (let* ((var-number (list-length vars)) (n (min non-repeaters var-number)) (m max-repetitions) (r (max (- var-number n) 0)) (real-vbs (mapcar #'(lambda (x) (coerce x 'list)) (coerce vbs 'list))) result-table) ;; non-repeaters (dotimes (i n) (push (pop real-vbs) result-table)) ;; table (when (and (plusp m) (plusp r)) (dotimes (i m) (push (let (record) (dotimes (j r (nreverse record)) (push (pop real-vbs) record))) result-table))) (values (nreverse result-table) (mapcar #'oid vars))))
If I temporary disable it by #+ignore or #-abcl, than the whole project compiles with no error any more. I'll try to continue look for which exactly form in this function caused the error.
Regards,
Chun Tian (binghe)
在 2011-3-21，19:21， Alessio Stalla 写道：
2011/3/21 Chun Tian (binghe) binghe.lisp@gmail.com:
Hi, Alessio
Thank you for pointing out this. You're right. IF I temporary removed the LOGAND form and just return the inner ATOMIC-INCF form, then everything goes well, compilation can pass.
The next issue happens in a file which has some method definitions, ABCL report "Register 4 contains wrong type" when loading a just compiled .abcl file:
; Loading #P"/Users/binghe/.cache/common-lisp/abcl-0.26.0-dev-svn-13251-fasl37-macosx-java/Users/binghe/Lisp/cl-net-snmp/snmp/branches/6/snmp-get.abcl" ...
Do you have any idea about this? i.e. What's "Register 4"?
It's a JVM register, used to hold some intermediate result. The compiler is producing incorrect code: probably it doesn't derive the right type for the atomic-incf form. I see that
(THREADS:WITH-MUTEX (PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*) (INCF REQUEST-ID-COUNTER 1))
expands to
(LET ((#:G3433 PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*)) (WHEN (THREADS:GET-MUTEX #:G3433) (UNWIND-PROTECT (PROGN (INCF REQUEST-ID-COUNTER 1)) (THREADS:RELEASE-MUTEX #:G3433))))
Maybe there's a problem with the derived type of unwind-protect forms, but I don't have the source at hand now to check.
Alessio