This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: _Cilk_spawn and _Cilk_sync for C++
- From: Jason Merrill <jason at redhat dot com>
- To: "Iyer, Balaji V" <balaji dot v dot iyer at intel dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Cc: Jeff Law <law at redhat dot com>
- Date: Wed, 27 Nov 2013 20:24:10 -0500
- Subject: Re: _Cilk_spawn and _Cilk_sync for C++
- Authentication-results: sourceware.org; auth=none
- References: <BF230D13CA30DD48930C31D4099330003A4A696B at FMSMSX101 dot amr dot corp dot intel dot com> <528E57DE dot 90900 at redhat dot com> <BF230D13CA30DD48930C31D4099330003A4AA318 at FMSMSX101 dot amr dot corp dot intel dot com> <528F7D81 dot 4000308 at redhat dot com> <BF230D13CA30DD48930C31D4099330003A4AC201 at FMSMSX101 dot amr dot corp dot intel dot com> <52962F1A dot 8090205 at redhat dot com> <BF230D13CA30DD48930C31D4099330003A4ACF94 at FMSMSX101 dot amr dot corp dot intel dot com> <5296407C dot 40907 at redhat dot com> <BF230D13CA30DD48930C31D4099330003A4AD241 at FMSMSX101 dot amr dot corp dot intel dot com>
On 11/27/2013 05:59 PM, Iyer, Balaji V wrote:
Well, if I use copy_tree_body_r for C and C++, in lambda functions, it asserts in varasm.c. The main reason I see that, the copy_tree_body_r walks into the closure and then maps the variables from the lambda function from the spawner to the helper function.
It walks into the initializer for the closure object, yes. And gets
confused by the initializer in the
_Cilk_spawn [=](int *Aa, int size){ foo1_c(A, size); }(B, 2);
case. The initializer for the closure is a CONSTRUCTOR which contains a
reference to A, and that is running into trouble because
extract_free_variables doesn't walk into CONSTRUCTORs. You probably
want to switch a lot of your tree walking functions to use walk_tree
directly rather than try to keep up with all the different kinds of
expressions yourself.
Jason