[armedbear-ticket] [armedbear] #214: Stack overflow when compiler macro with fallback is triggered
#214: Stack overflow when compiler macro with fallback is triggered ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: compiler | Version: 1.0.1 Keywords: | ----------------------+----------------------------------------------------- [http://article.gmane.org/gmane.lisp.armedbear.devel/2352 James Lawerence reports]
{{{ (eval-when (:compile-toplevel :load-toplevel :execute) (defun foo () 99)
(define-compiler-macro foo () `(locally (declare (notinline foo)) (foo))))
(defun call-foo () (foo)) }}}
Of course, the use case is a compiler macro that says, "OK, let's optimize! ... Never mind, I don't want to optimize that."
{{{ Armed Bear Common Lisp 1.0.1-svn-13750-13751 Java 1.7.0_04 Oracle Corporation [...] ; (DEFUN FOO ...) ; (DEFINE-COMPILER-MACRO FOO ...) ; (DEFUN CALL-FOO ...) java.lang.StackOverflowError at org.armedbear.lisp.StructureObject$pf_make_structure.execute(StructureObject.java:671) at org.armedbear.lisp.Symbol.execute(Symbol.java:865) at org.armedbear.lisp.LispThread.execute(LispThread.java:760) at org.armedbear.lisp.jvm_714.execute(jvm.lisp:567) }}}
#214: Stack overflow when compiler macro with fallback is triggered ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: minor | Milestone: 1.1.0 Component: compiler | Version: 1.0.1 Keywords: | ----------------------+----------------------------------------------------- Changes (by ehuelsmann):
* priority: major => minor
Comment:
To James the response has already been that if a compiler macro chooses not to handle a form, it should return the original.
However, I do agree it's not nice that the compiler macro here tries to inline the call to FOO while it should have been marked as notinline.
#214: Stack overflow when compiler macro with fallback is triggered ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: minor | Milestone: 1.1.0 Component: compiler | Version: 1.0.1 Keywords: | ----------------------+-----------------------------------------------------
Comment(by ehuelsmann):
The key to the issue is compiler-pass1: it doesn't use WITH-SAVED- COMPILER-POLICY and PROCESS-OPTIMIZATION-DECLARATIONS to let the user (locally) change settings on inline expansion or not.
Note that this has otherwise little impact: code generation happens in phase 2 which does take advantage of local settings for inlining, speed and debugging.
#214: Stack overflow when compiler macro with fallback is triggered ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: accepted Priority: minor | Milestone: 1.1.0 Component: compiler | Version: 1.0.1 Keywords: | ----------------------+----------------------------------------------------- Changes (by ehuelsmann):
* status: new => accepted
#214: Stack overflow when compiler macro with fallback is triggered ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: accepted Priority: minor | Milestone: 1.1.0 Component: compiler | Version: 1.0.1 Keywords: | ----------------------+-----------------------------------------------------
Comment(by https://www.google.com/accounts/o8/id?id=aitoawnrjeu10nytjdblqsat_gbkbigkyi8...):
I realize you've already accepted the ticket, but to clarify the purpose here (maybe you missed my follow-up) -- sometimes fallback is decided inside the expansion, where we pass the already-evaluated arguments to the notinline call.
Ideally fallback is determined at compile-time, but that's not always possible.
#214: Stack overflow when compiler macro with fallback is triggered -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: closed Priority: minor | Milestone: 1.1.0 Component: compiler | Version: 1.0.1 Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Changes (by ehuelsmann):
* status: accepted => closed * resolution: => fixed
Comment:
(In [14075]) Fix #214: NOTINLINE declaration in expansion of compiler macro is ignored.
Note: The truth be told, but all optimization declarations (inline/ notinnline) were ignored in pass1, except in some rare cases.
armedbear-ticket@common-lisp.net
-
armedbear