This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gomp4] Adjust Fortran OACC async lib test
- From: Thomas Schwinge <thomas at codesourcery dot com>
- To: Chung-Lin Tang <cltang at codesourcery dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, James Norris <jnorris at codesourcery dot com>
- Date: Tue, 8 Dec 2015 12:45:57 +0100
- Subject: Re: [gomp4] Adjust Fortran OACC async lib test
- Authentication-results: sourceware.org; auth=none
- References: <87pp0aaksc dot fsf at kepler dot schwinge dot homeip dot net> <56543B8C dot 404 at codesourcery dot com> <56531154 dot 9080606 at codesourcery dot com> <56628C72 dot 9040802 at codesourcery dot com> <5652F3F0 dot 906 at codesourcery dot com>
Hi!
On Mon, 23 Nov 2015 19:09:36 +0800, Chung-Lin Tang <cltang@codesourcery.com> wrote:
> this fix adds more acc_wait's to libgomp.oacc-fortran/lib-1[13].f90.
It has not been obvious to me that these test cases would regress (PASS
-> FAIL, at least for some optimization levels) when your recent "[PATCH,
libgomp] Rewire OpenACC async" is applied. Likewise for the testcase
affected ("repaired") by "[PATCH, C++] Wrap OpenACC wait in EXPR_STMT",
libgomp.oacc-c++/template-reduction.C. Aside from verbally noting such
dependencies between patches and test cases, that latter patch submission
(for trunk) could have included (something like) this gomp-4_0-branch
libgomp.oacc-c++/template-reduction.C test case, to motivate the code
change, for example.
> For lib-12.f90, it's sort of a fix before we can resolve the issue
> of intended semantics for "wait+async".
>
> As for lib-13.f90, I believe these added acc_wait calls seem
> reasonable, since we can't immediately assume the async-launched parallels
> already completed there.
>
> Does this seem reasonable?
I think (and Jim, original author of these tests, copied to correct me if
I'm wrong) the intention of these tests is to launch a kernel
asynchronously, running long enough so that in the following we can test
that it's still running, enqueue asynchronous waits, and so on
(acc_sync_test, acc_wait_async, and so on). Adding acc_wait calls
renders any such testing void?
However, isn't currently the logic written the wrong way round? That is,
currently we abort if there are still asynchronous operations running,
which would explain why your change to add acc_wait calls does fix these
tests...
(And, of course a simple "do i = 1, 1000000: j = j + 1" loop is not
really a bullet-proof way to achieve such a long-running kernel...)
Given these problems, I suggest indeed you do commit your patch, and I'll
make a note that these test cases need to be revisited.
When committing this, please also remove the XFAIL directives from
libgomp.oacc-c-c++-common/asyncwait-1.c, which you forgot to do in your
gomp-4_0-branch "[PATCH, libgomp] Rewire OpenACC async" commit.
> Index: libgomp.oacc-fortran/lib-12.f90
> ===================================================================
> --- libgomp.oacc-fortran/lib-12.f90 (revision 230719)
> +++ libgomp.oacc-fortran/lib-12.f90 (working copy)
> @@ -15,6 +15,8 @@ program main
> end do
> !$acc end parallel
>
> + call acc_wait (0)
> +
> call acc_wait_async (0, 1)
>
> if (acc_async_test (0) .neqv. .TRUE.) call abort
> Index: libgomp.oacc-fortran/lib-13.f90
> ===================================================================
> --- libgomp.oacc-fortran/lib-13.f90 (revision 230719)
> +++ libgomp.oacc-fortran/lib-13.f90 (working copy)
> @@ -21,6 +21,9 @@ program main
> end do
> !$acc end data
>
> + call acc_wait (1)
> + call acc_wait (2)
> +
> if (acc_async_test (1) .neqv. .TRUE.) call abort
> if (acc_async_test (2) .neqv. .TRUE.) call abort
GrÃÃe
Thomas