https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- Don't know Cilk+ but yes, try for (int i=0; i<8; i++) { std::vector<int> vnew(v); vnew.push_back(i); cilk_spawn walk(vnew, size); cilk_sync; } with appropriate syntax. We expand the spawn like try { <<cleanup_point <<< Unknown tree: expr_stmt std::vector<int>::push_back (&vnew, (const value_type &) &i) >>>>>; <<cleanup_point <<< Unknown tree: expr_stmt _Cilk_spawn walk (&TARGET_EXPR <D.15394, <<< Unknown tree: aggr_init_expr 5 __comp_ctor D.15394 (struct vector *) <<< Unknown tree: void_cst >>> (const struct vector &) &vnew >>>>, size) >>>>>; } finally { std::vector<int>::~vector (&vnew); } which means the spawned copies use a shared vnew and a single destructor is run "afterwards". If there's no synchronization then all threads will call the destructor I guess. Not sure if cilk_sync will properly "merge" execution back to one thread or if there's another primitive that does that. Cilk+ and C++ is going to be "interesting" with these kind of issues.