[Bug libgomp/58378] Protect libgomp against child process hanging after a Unix fork()

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58378

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Please read OpenMP 4.0, section 2.14.2 (threadprivate directive), or
corresponding sections in older standards.
The implementation must preserve values of threadprivate variables in certain
cases, which your hack violates.  If somebody (validly) does:
int v;
#pragma omp threadprivate (v)
...
omp_set_dynamic (0);
#pragma omp parallel num_threads (4)
{
  v = omp_get_thread_num () * 16;
}
...
pid = fork ();
if (pid == 0)
  {
    /* Valid fork child, only calling functions POSIX allows it to.  */
    execve (...);
  }

#pragma omp parallel num_threads (4)
{
  if (v != omp_get_thread_num () * 16)
    abort ();
}

then the implementation must preserve the threadprivate values, but with your
patch all the threads but the initial one will be lost during fork and thus v
will be 0 instead of the desired value later on.

There is no point trying to hack around bugs in your code inside of libgomp,
simply follow the requirements how you can use fork in multithreaded apps.