This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/80038] Random segfault using local vectors in Cilk function
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 14 Mar 2017 10:07:43 +0000
- Subject: [Bug c++/80038] Random segfault using local vectors in Cilk function
- Auto-submitted: auto-generated
- References: <bug-80038-4@http.gcc.gnu.org/bugzilla/>
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.