This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gomp4.5] depend nowait support for target
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Ilya Verbin <iverbin at gmail dot com>
- Cc: Aldy Hernandez <aldyh at redhat dot com>, gcc-patches at gcc dot gnu dot org, Kirill Yukhin <kirill dot yukhin at gmail dot com>, Thomas Schwinge <thomas at codesourcery dot com>, Alexander Monakov <amonakov at ispras dot ru>, Martin Jambor <mjambor at suse dot cz>
- Date: Fri, 13 Nov 2015 11:18:41 +0100
- Subject: Re: [gomp4.5] depend nowait support for target
- Authentication-results: sourceware.org; auth=none
- References: <20150908092014 dot GA1847 at tucnak dot redhat dot com> <20151002192801 dot GA24765 at msticlxl57 dot ims dot intel dot com> <20151015140156 dot GE478 at tucnak dot redhat dot com> <20151019194754 dot GB1855 at msticlxl57 dot ims dot intel dot com> <20151111165222 dot GL5675 at tucnak dot redhat dot com> <20151112174509 dot GG5675 at tucnak dot redhat dot com> <20151112205133 dot GC4917 at msticlxl57 dot ims dot intel dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Nov 12, 2015 at 11:51:33PM +0300, Ilya Verbin wrote:
> I'm unable to reproduce the hang (have tried various values of OMP_NUM_THREADS).
> The testcase just aborts at (a != 50 || b != 4 || c != 20), because
> a == 37, b == 12, c == 40.
The hang has been with a fprintf (stderr, "...\n"); inside of the parallel
regions. Anyway, still can't reproduce target-32.c crash, the target-33.c
abort is due to thinko (a, b, c were firstprivate in the explicit tasks, so
no wonder it could see the previous values). See the following incremental
patch.
> BTW, don't know is this a bug or not:
> Conditional jump or move depends on uninitialised value(s)
> at 0x4C2083D: priority_queue_insert (priority_queue.h:347)
> by 0x4C24DF9: GOMP_PLUGIN_target_task_completion (task.c:678)
This is due to uninitialized task->priority for the target task. See below.
Now I'm fighting target-34.c test hangs, strangely it hangs even with host
fallback.
For the offloading case, I actually see a problematic spot, namely that
GOMP_PLUGIN_target_task_completion could finish too early, and get the
task_lock before the thread that run the gomp_target_task_fn doing map_vars
+ async_run for it. Bet I need to add further ttask state kinds and deal
with that case (so GOMP_PLUGIN_target_task_completion would just take the
task lock and tweak ttask state if it has not been added to the queues
yet).
Plus I think I want to improve the case where we are not waiting, in
gomp_create_target_task if not waiting for dependencies actually schedule
manually the gomp_target_task_fn.
--- libgomp/testsuite/libgomp.c/target-33.c 2015-11-12 16:20:14.000000000 +0100
+++ libgomp/testsuite/libgomp.c/target-33.c 2015-11-13 09:45:27.174427034 +0100
@@ -61,10 +61,10 @@
a = a + 4;
c >>= 1;
}
- #pragma omp task if (0) depend (in: d[3], d[4])
+ #pragma omp task if (0) depend (in: d[3], d[4]) shared (a, b, c)
if (a != 50 || b != 4 || c != 20)
abort ();
- #pragma omp task
+ #pragma omp task shared (a)
a += 50;
#pragma omp target nowait map (tofrom: b)
b++;
--- libgomp/task.c 2015-11-12 16:24:19.127548800 +0100
+++ libgomp/task.c 2015-11-13 10:53:19.525519366 +0100
@@ -538,6 +538,7 @@
+ sizeof (unsigned short))
+ tgt_size);
gomp_init_task (task, parent, gomp_icv (false));
+ task->priority = 0;
task->kind = GOMP_TASK_WAITING;
task->in_tied_task = parent->in_tied_task;
task->taskgroup = taskgroup;
--- libgomp/testsuite/libgomp.c/target-34.c.jj 2015-11-13 08:54:42.607799433 +0100
+++ libgomp/testsuite/libgomp.c/target-34.c 2015-11-13 08:54:37.865866795 +0100
@@ -0,0 +1,12 @@
+#define main do_main
+#include "target-33.c"
+#undef main
+
+int
+main ()
+{
+ #pragma omp parallel
+ #pragma omp single
+ do_main ();
+ return 0;
+}
Jakub