https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #10 from Xi Ruoyao <ryxi at stu dot xidian.edu.cn> --- (In reply to Richard Biener from comment #3) > 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. I don't think so. I peeked into the assembly code generated. A temp copy of vnew is generated for "cilk_spawn walk(...)" just like there is a simple walk(...) call. However the temp is soon destroyed after cilk_spawn returned. And at the point the child is still running and reading that temp copy. It's easy to find out using -fsanitize=thread. > Cilk+ and C++ is going to be "interesting" with these kind of issues. It's clear in cilkplus spec <https://www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm> section 3.6 bullet [4]: > Any unnamed temporary variables created prior to the spawn point are > not destroyed until after the spawn point (i.e., their destructors are > invoked in the child). But GCC is invoking destructors in the *parent*. That caused this issue. In fact Florent's workaround in comment 5 is exactly doing what the spec said. We may let GCC generate code like this. But then the temp would be in the heap instead of stack. To keep the temp living and the parent running, if we want to use stack, we have to alloc this temp on the stack of the *child*. Currently I have no idea how to do this.
