On Thu, Dec 01, 2011 at 09:58:08PM +1030, Alan Modra wrote: > The GOMP_task change fixes a similar potential problem. Bootstrapped > and regression tested powerpc-linux. OK to apply? > > PR libgomp/51376 > * task.c (GOMP_taskwait): Don't access task->children outside of > task_lock mutex region. > (GOMP_task): Likewise.
Can't this be solved just by adding a barrier? The access to the var outside of the lock has been quite intentional, to avoid locking in the common case where there are no children. > --- libgomp/task.c (revision 181833) > +++ libgomp/task.c (working copy) > @@ -116,12 +116,12 @@ GOMP_task (void (*fn) (void *), void *da > } > else > fn (data); > - if (task.children) > - { > - gomp_mutex_lock (&team->task_lock); > - gomp_clear_parent (task.children); > - gomp_mutex_unlock (&team->task_lock); > - } > + if (team != NULL) > + gomp_mutex_lock (&team->task_lock); > + if (task.children != NULL) > + gomp_clear_parent (task.children); > + if (team != NULL) > + gomp_mutex_unlock (&team->task_lock); > gomp_end_task (); > } > else > @@ -290,8 +290,9 @@ GOMP_taskwait (void) > struct gomp_task *child_task = NULL; > struct gomp_task *to_free = NULL; > > - if (task == NULL || task->children == NULL) > + if (task == NULL) > return; > + > gomp_mutex_lock (&team->task_lock); > while (1) > { Jakub