[armedbear-devel] Stack overflow when compiler macro with fallback is triggered
ehuels at gmail.com
Sun Aug 12 20:56:43 UTC 2012
Just committed the fix for the test case which I had in ticket #214 - taken
from your report below.
So, it's fixed in trunk!
Hopefully we can come up with a good protocol for the "interrupted" threads
to be able to terminate threads in a nice unwind-protected manner.
Anyway, we're a small step closer to correctly (completely) running
On Fri, Jun 15, 2012 at 3:31 PM, James M. Lawrence <llmjjmll at gmail.com>wrote:
> [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>
> > 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]; thanks for the report!
> >> : 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
> 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 :)
> armedbear-devel mailing list
> armedbear-devel at common-lisp.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the armedbear-devel