Opened 13 years ago
Closed 12 years ago
#214 closed defect (fixed)
Stack overflow when compiler macro with fallback is triggered
Reported by: | Mark Evenson | Owned by: | ehuelsmann |
---|---|---|---|
Priority: | minor | Milestone: | 1.1.0 |
Component: | compiler | Version: | 1.0.1 |
Keywords: | Cc: | ||
Parent Tickets: |
Description
(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)
Change History (5)
comment:1 Changed 12 years ago by
Priority: | major → minor |
---|
comment:2 Changed 12 years ago by
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.
comment:3 Changed 12 years ago by
Status: | new → accepted |
---|
comment:4 Changed 12 years ago by
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.
comment:5 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
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.