Patch attached that should fix this issue. Root cause: when I added the with-operand-accumulation forms for opstack safety (to fix the stack inconsistency bug reported in #69 [0]), I had incorrect types specified in some of the p2-ash code paths. The form (ash 1343225879 (- 1)) also was not being compiled as a constant, and took a code path to actually calculate the shift based on the -1 constant. In the patch attached I:
- Added a constant folding case if arg2 was detected as a constant (but wasn't a literal integer, such as (- 1) ) - Fixed all with-operand-accumulation forms to have the correct types - Added test cases that exercise all code paths of p2-ash
Patch is applied againt: https://github.com/armedbear/abcl Latest master (3a54c91f3a0cbb71ae8d161acadecf118a65404c).
Please let me know if there is any more troubles,
-Mark
[0] https://github.com/armedbear/abcl/issues/69
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, December 15, 2019 6:12 PM, somewhat-functional-programmer somewhat-functional-programmer@protonmail.com wrote:
Thank you for sending in this form -- I apologize - I am certain that this was introduced by my patch earlier this year to fix a couple of stack inconsistency bugs[0] -- a result of my modification to the p2-ash function.
An minimal form that reproduces this bug: (let ((fn (compile nil '(lambda () (ash 1343225879 (- 1)))))) (funcall fn))
In this particular case, (ash 1343225879 (- 1)) should compile to a constant, but doesn't, and the particular Java verification error stems from trying to load and store the -1 constant using aload/astore* instead of iload*. I have a local fix for this, and am also generating test cases with different types specified to exercise all possible code paths in p2-ash (such as): (the fixnum (ash (the fixnum x) 2))
Sorry for the trouble! And again, thanks for sending this in, especially something so small and reproducible.
I hope to be able to contribute more to ABCL this year if it makes sense, but at the very least can help fix this problem I introduced, I should be able to send out a patch tonight or at least very soon,
-Mark
[0] https://mailman.common-lisp.net/pipermail/armedbear-devel/2019-May/003977.ht...
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Saturday, December 14, 2019 9:43 AM, Eric Marsden eric.marsden@free.fr wrote:
Hi, Compiling the loading the code below (a simplified extract of SBCL's codebase, found attempting to crossbuild SBCL with ABCL) results in a VerifyError, possibly related to the implementation of PROGN. Using 1.6.1-dev-svn-15217. java.lang.VerifyError: (class: org/armedbear/lisp/foo_1, method: execute signature: (Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Expecting to find object/array on stack at java.base/java.lang.Class.getDeclaredConstructors0(Native Method) at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3137) at java.base/java.lang.Class.getConstructor0(Class.java:3342) at java.base/java.lang.Class.newInstance(Class.java:556) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:273) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Load.faslLoadStream(Load.java:667) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457)
(in-package :cl-user) (progn (defvarsxhash-crosscheck nil) (defun sxhash (x) (let ((answer (if (string= x "NIL") (ash 1343225879 (- 1))))) (push (cons x answer)sxhash-crosscheck) answer))) -- Eric Marsden https://risk-engineering.org/