On 12/03/2013 02:48 PM, Iyer, Balaji V wrote:
Now, after all that I must admit that cilk_spawn could only ever see
VEC_INIT_EXPR in the context of a lambda closure initialization, and the
default behavior should always be correct for a lambda closure initialization,
so I guess I'm willing to allow the magic lambda handling with a comment
about it being a workaround.
Thanks for this! Where should I put this comment?
In cp_cilk_install_body_wframe_cleanup, before the lambda handling.
Here you're pre-evaluating the entire call, rather than just the lambda
closure object, which means none of the arguments to the call will be
remapped. I think you want
I stabilize the call here, and then I call cilk_outline on the pre_body which
will do the outlining of the arguments.
Ah, I see. Then the stabilization isn't actually making a difference,
as you're just shuffling things around rather than actually hiding them.
And indeed removing the special lambda handling doesn't prevent the
tests from passing. What's actually different about this patch is that
you pass pre_body to cilk_outline and then ignore any changes
cilk_outline made to it: the rest of the function goes back to looking
at orig_body. If I change the later references to use pre_body, we
still get the crash.
+ error_at (input_location, "_Cilk_sync cannot be used without enabling"
+ "Cilk Plus");
+ cp_lexer_consume_token (parser->lexer);
+ if (parser->in_statement & IN_CILK_SPAWN)
+ parser->in_statement = parser->in_statement & ~IN_CILK_SPAWN;
Why are you messing with in_statement in the cilk_spawn code?
This needed to catch cases like this:
_Cilk_spawn _Cilk_spawn foo ()
Oops, I meant to say "in the cilk_sync code". Why does finding a
_Cilk_sync end the _Cilk_spawn context?
Jason
