Hello

This patch addresses the intermittent hanging seen in the 
libgomp.c-c++-common/task-detach-6.f90 test.

The main problem is due to the 'omp taskwait' in the test. GOMP_taskwait can run 
tasks, so for correct semantics it needs to be able to place finished tasks that 
have unfulfilled completion events into the detach queue, rather than just 
finishing them immediately (in effect ignoring the detach clause).

Unfinished tasks in the detach queue are still children of their parent task, so 
they can appear in next_task in the main GOMP_taskwait loop. If next_task is 
fulfilled then it can be finished immediately, otherwise it will wait on 
taskwait_sem.

omp_fulfill_event needs to be able to post the taskwait_sem semaphore as well as 
wake the team barrier. Since the semaphore is located on the parent of the task 
whose completion event is being fulfilled, I have changed the event handle to 
being a pointer to the task instead of just the completion semaphore in order to 
access the parent field.

This type of code is currently used to wake the threads for the team barrier:

   if (team->nthreads > team->task_running_count)
     gomp_team_barrier_wake (&team->barrier, 1);

This issues a gomp_team_barrier_wake if any of the threads are not running a 
task (and so might be sleeping). However, detach tasks that are queued waiting 
for a completion event are currently included in task_running_count (because the 
finish_cancelled code executed later decrements it). Since 
gomp_barrier_handle_tasks does not block if there are unfinished detached tasks 
remaining (since during development I found that doing so could cause deadlocks 
in single-threaded code), threads could be sleeping even if team->nthreads == 
team->task_running_count, and this code would fail to wake them. I fixed this by 
decrementing task_running_count when queuing an unfinished detach task, and 
skipping the decrement in finish_cancelled if the task was a queued detach tash. 
I added a new gomp_task_kind GOMP_TASK_DETACHED to mark these type of tasks.

I have tried running the task-detach-6 testcase (C and Fortran) 10,000 
iterations at a time using 32 threads, on a x86_64 Linux machine with GCC built 
with --disable-linux-futex, and no hangs. I have checked that it bootstraps, and 
noticed no regressions in the libgomp testsuite when run without offloading.

With Nvidia and GCN offloading though, task-detach-6 hangs... I _think_ the 
reason why it 'worked' before was because the taskwait allowed tasks with detach 
clauses to always complete immediately after execution. Since that backdoor has 
been closed, task-detach-6 hangs with or without the taskwait.

I think GOMP_taskgroup_end and maybe gomp_task_maybe_wait_for_dependencies also 
need the same type of TLC as they can also run tasks, but there are currently no 
tests that exercise it.

The detach support clearly needs more work, but is this particular patch okay 
for trunk?

Thanks

Kwok