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

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)

Change History (5)

comment:1 Changed 12 years ago by ehuelsmann

Priority: majorminor

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.

comment:2 Changed 12 years ago 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.

comment:3 Changed 12 years ago by ehuelsmann

Status: newaccepted

comment:4 Changed 12 years ago by Llmjjmll

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 ehuelsmann

Resolution: fixed
Status: acceptedclosed

(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.

Note: See TracTickets for help on using tickets.