[PATCH] allow deferred-shape pointers in OpenACC data clauses

[PATCH] allow deferred-shape pointers in OpenACC data clauses

[Cesar Philippidis]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

This patch teaches the fortran FE to allow deferred-shape pointers to be
used in OpenACC data clauses. While the spec states that arrays must be
contiguous, I believe that is a run-time requirement, not a compile
time. The intent behind OpenACC is to have the programmer sprinkle a
minimum amount of ACC directives on their existing code base, and have
the compiler generate offloading code. In this case, the deferred-shape
pointer check was preventing working code from compiling.

I was considering relaxing the error to a warning, but I ended up
deciding this should be a run-time failure, if there is one.

Is this OK for trunk? I tested it on x86_64 with nvptx offloading.

Cesar


[-- Attachment #2: gfc-deferred-shape-pointers.diff --]
[-- Type: text/x-patch, Size: 1515 bytes --]

2017-07-14  Cesar Philippidis  <cesar@codesourcery.com>

	gcc/fortran/
	* openmp.c (check_array_not_assumed): Don't error on noncontiguous
	deferred-shape pointers.

	gcc/testsuite/
	* gfortran.dg/goacc/deferred-shape-pointer.f90: New test.


diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 8400354181c..f08a37e0d89 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -3774,10 +3774,6 @@ check_array_not_assumed (gfc_symbol *sym, locus loc, const char *name)
   if (sym->as && sym->as->type == AS_ASSUMED_RANK)
     gfc_error ("Assumed rank array %qs in %s clause at %L",
 	       sym->name, name, &loc);
-  if (sym->as && sym->as->type == AS_DEFERRED && sym->attr.pointer
-      && !sym->attr.contiguous)
-    gfc_error ("Noncontiguous deferred shape array %qs in %s clause at %L",
-	       sym->name, name, &loc);
 }
 
 static void
diff --git a/gcc/testsuite/gfortran.dg/goacc/deferred-shape-pointer.f90 b/gcc/testsuite/gfortran.dg/goacc/deferred-shape-pointer.f90
new file mode 100644
index 00000000000..e0d0b8dd916
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/deferred-shape-pointer.f90
@@ -0,0 +1,20 @@
+! Test support of deferred-shape pointers.
+
+subroutine foo (x, y, z)
+  implicit none
+
+  integer :: y, z, i
+  integer,target :: x(y:z)
+  integer, pointer, dimension(:) :: px
+
+  px => x
+
+  !$acc data present(px)
+  !$acc end data
+
+  !$acc parallel loop present(px)
+  do i = 1, z
+     px(i) = px(i) * 2
+  end do
+  !$acc end parallel loop
+end subroutine foo

Re: [PATCH] allow deferred-shape pointers in OpenACC data clauses

[Thomas Koenig]

Am 14.07.2017 um 16:11 schrieb Cesar Philippidis:
> This patch teaches the fortran FE to allow deferred-shape pointers to be
> used in OpenACC data clauses. While the spec states that arrays must be
> contiguous, I believe that is a run-time requirement, not a compile
> time. The intent behind OpenACC is to have the programmer sprinkle a
> minimum amount of ACC directives on their existing code base, and have
> the compiler generate offloading code. In this case, the deferred-shape
> pointer check was preventing working code from compiling.

It is possible to declare a pointer with the contiguous attribute.
Is there a reason that this cannot be used in general=

> I was considering relaxing the error to a warning, but I ended up
> deciding this should be a run-time failure, if there is one.

What happens - silent wrong-code or indeed a run-time error which
lets the user know what is wrong?

> Is this OK for trunk? I tested it on x86_64 with nvptx offloading.

Does any of the gfortran maintaiers have access to a machine which
allows nvptx offloading?  I lack both the hardware and the know-how :-)

Regards

	Thomas

Re: [PATCH] allow deferred-shape pointers in OpenACC data clauses

[Cesar Philippidis]

On 07/16/2017 10:28 AM, Thomas Koenig wrote:
> Am 14.07.2017 um 16:11 schrieb Cesar Philippidis:
>> This patch teaches the fortran FE to allow deferred-shape pointers to be
>> used in OpenACC data clauses. While the spec states that arrays must be
>> contiguous, I believe that is a run-time requirement, not a compile
>> time. The intent behind OpenACC is to have the programmer sprinkle a
>> minimum amount of ACC directives on their existing code base, and have
>> the compiler generate offloading code. In this case, the deferred-shape
>> pointer check was preventing working code from compiling.
> 
> It is possible to declare a pointer with the contiguous attribute.
> Is there a reason that this cannot be used in general=

That's a good point. But some users don't want to modify their programs
more beyond adding OpenACC directives.

>> I was considering relaxing the error to a warning, but I ended up
>> deciding this should be a run-time failure, if there is one.
> 
> What happens - silent wrong-code or indeed a run-time error which
> lets the user know what is wrong?

It would be a run-time error, like a segmentation fault.

>> Is this OK for trunk? I tested it on x86_64 with nvptx offloading.
> 
> Does any of the gfortran maintaiers have access to a machine which
> allows nvptx offloading?  I lack both the hardware and the know-how :-)

I don't know.

Cesar

Re: [PATCH] allow deferred-shape pointers in OpenACC data clauses

[Thomas Koenig]

Am 17.07.2017 um 00:31 schrieb Cesar Philippidis:
> On 07/16/2017 10:28 AM, Thomas Koenig wrote:

>> It is possible to declare a pointer with the contiguous attribute.
>> Is there a reason that this cannot be used in general=
> 
> That's a good point. But some users don't want to modify their programs
> more beyond adding OpenACC directives.


Hm, I can understand that, at least partially, because CONTIGUOUS is
a F2008 feature which my be rejected by compilers which do not
implement it.


>>> I was considering relaxing the error to a warning, but I ended up
>>> deciding this should be a run-time failure, if there is one.
>>
>> What happens - silent wrong-code or indeed a run-time error which
>> lets the user know what is wrong?
> 
> It would be a run-time error, like a segmentation fault.

What do you think about changing it into a warning enabled with -Wall?
OK if you agree, otherwise we can continue the discussion.

Regards

	Thomas