[armedbear-devel] Stack overflow when compiler macro with fallback is triggered

[James M. Lawrence]

[I just noticed this wasn't sent to the list.]

On Tue, Jun 5, 2012 at 8:41 AM, Alessio Stalla <alessiostalla at gmail.com> wrote:
> On Tue, Jun 5, 2012 at 2:30 PM, Mark Evenson <evenson at panix.com> wrote:
>>
>> On Jun 3, 2012, at 22:19 , James M. Lawrence wrote:
>>
>>> (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."
>>
>> Filed [as ticket #214][1]; thanks for the report!
>>
>> [1]: http://trac.common-lisp.net/armedbear/ticket/214
>
> Shouldn't &whole be used for that?

Yes I do use a &whole parameter, which handles the case of the
fallback being determined at compile time. Once I have evaluated a
parameter, however, the fallback goes to a notinline call inside the
expansion.

My example is pmap-into, which has the vector-into-vector case
open-coded. It would be neat if a macro could query declared or
inferred types, but failing that we must evaluate and check.

Thanks to all for the endorsement :)