Add map clauses to libgomp test device-3.f90

On Tue, 15 Nov 2016, Alexander Monakov wrote:
> Yep, I do see new test execution failures with both Intel MIC and PTX offloading
> on device-1.f90, device-3.f90 and target2.f90.  Here's an actually-tested patch
> for the first two (on target2.f90 there's a different problem).

And here's a patch for target2.f90.  I don't have a perfect understanding of
mapping clauses, but the test appears to need to explicitly map pointer
variables, at a minimum.  Also, 'map (from: r)' is missing on the last target
region.

	* testsuite/libgomp.fortran/target2.f90 (foo): Add mapping clauses to
	target construct.

On Tue, 15 Nov 2016, Alexander Monakov wrote:
> On Tue, 15 Nov 2016, Alexander Monakov wrote:
> > Yep, I do see new test execution failures with both Intel MIC and PTX offloading
> > on device-1.f90, device-3.f90 and target2.f90.  Here's an actually-tested patch
> > for the first two (on target2.f90 there's a different problem).
> 
> And here's a patch for target2.f90.  I don't have a perfect understanding of
> mapping clauses, but the test appears to need to explicitly map pointer
> variables, at a minimum.  Also, 'map (from: r)' is missing on the last target
> region.
> 
> 	* testsuite/libgomp.fortran/target2.f90 (foo): Add mapping clauses to
> 	target construct.

Ping.

> diff --git a/libgomp/testsuite/libgomp.fortran/target2.f90 b/libgomp/testsuite/libgomp.fortran/target2.f90
> index 42f704f..7119774 100644
> --- a/libgomp/testsuite/libgomp.fortran/target2.f90
> +++ b/libgomp/testsuite/libgomp.fortran/target2.f90
> @@ -63,7 +63,7 @@ contains
>        r = r .or. (any (k(5:n-5) /= 17)) .or. (lbound (k, 1) /= 4) .or. (ubound (k, 1) /= n)
>      !$omp end target
>      if (r) call abort
> -    !$omp target map (to: d(2:n+1), n)
> +    !$omp target map (to: d(2:n+1), f, j) map (from: r)
>        r = a /= 7
>        r = r .or. (any (b /= 8)) .or. (lbound (b, 1) /= 3) .or. (ubound (b, 1) /= n)
>        r = r .or. (any (c /= 9)) .or. (lbound (c, 1) /= 5) .or. (ubound (c, 1) /= n + 4)
> 
>

On Tue, Nov 15, 2016 at 08:01:32PM +0300, Alexander Monakov wrote:
> On Tue, 15 Nov 2016, Alexander Monakov wrote:
> > Yep, I do see new test execution failures with both Intel MIC and PTX offloading
> > on device-1.f90, device-3.f90 and target2.f90.  Here's an actually-tested patch
> > for the first two (on target2.f90 there's a different problem).
> 
> And here's a patch for target2.f90.  I don't have a perfect understanding of
> mapping clauses, but the test appears to need to explicitly map pointer
> variables, at a minimum.  Also, 'map (from: r)' is missing on the last target
> region.
> 
> 	* testsuite/libgomp.fortran/target2.f90 (foo): Add mapping clauses to
> 	target construct.
> 
> diff --git a/libgomp/testsuite/libgomp.fortran/target2.f90 b/libgomp/testsuite/libgomp.fortran/target2.f90
> index 42f704f..7119774 100644
> --- a/libgomp/testsuite/libgomp.fortran/target2.f90
> +++ b/libgomp/testsuite/libgomp.fortran/target2.f90
> @@ -63,7 +63,7 @@ contains
>        r = r .or. (any (k(5:n-5) /= 17)) .or. (lbound (k, 1) /= 4) .or. (ubound (k, 1) /= n)
>      !$omp end target
>      if (r) call abort
> -    !$omp target map (to: d(2:n+1), n)
> +    !$omp target map (to: d(2:n+1), f, j) map (from: r)

The missing map (from: r) is obvious.  Explicitly mentioned f and j is
tested in another part of the test, here I believe it should be implicitly
firstprivate, and then
"If the original list item has the POINTER attribute, the new list items
receive the same association status of the original list item as if by
pointer assignment."
shall apply.  I think I'd prefer the test to be broken over forgetting this
isn't handled correctly.

	Jakub