This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/80038] Random segfault using local vectors in Cilk function


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]