Re: [gomp4] Adjust Fortran OACC async lib test

[Thomas Schwinge]

Hi!

On Mon, 23 Nov 2015 19:09:36 +0800, Chung-Lin Tang  
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, 100: 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

Re: [gomp4] Adjust Fortran OACC async lib test

[Chung-Lin Tang]

Ping.

Hi Thomas, this is only for gomp4 ATM, okay to commit?

Thanks,
Chung-Lin

On 2015/11/23 7:09 PM, Chung-Lin Tang wrote:
> Hi Thomas,
> this fix adds more acc_wait's to libgomp.oacc-fortran/lib-1[13].f90.
> 
> 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?
> 
> Thanks,
> Chung-Lin
> 
>   * testsuite/libgomp.oacc-fortran/lib-12.f90 (main): Add acc_wait()
>   after async parallel construct.
>   * testsuite/libgomp.oacc-fortran/lib-13.f90 (main): Add acc_wait()
>   calls after parallel construct launches.
> 

[gomp4] Adjust Fortran OACC async lib test

[Chung-Lin Tang]

Hi Thomas,
this fix adds more acc_wait's to libgomp.oacc-fortran/lib-1[13].f90.

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?

Thanks,
Chung-Lin

* testsuite/libgomp.oacc-fortran/lib-12.f90 (main): Add acc_wait()
after async parallel construct.
* testsuite/libgomp.oacc-fortran/lib-13.f90 (main): Add acc_wait()
calls after parallel construct launches.
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