[PATCH 1/6] [GOMP4] OpenACC 1.0+ support in fortran front-end

[Tobias Burnus]

Hi Ilmir,

thanks for your reply; I am looking forward to your updated patch.

Ilmir Usmanov wrote:
> I have tested your notes on two compilers which support OpenACC: PGI 
> 14.1 and CAPS 3.4.1.

I can add Cray ftn results, if you want me to cross-check something.

> On 10.02.2014 02:22, Tobias Burnus wrote:
>>
>> a) Does this part work well when both -fopenmp and -fopenacc is used? 
>> I mean: "!$acc loop" followed/preceded by "!$omp do"? I could imagine 
>> that there could be clashes, especially when - e.g. - collapse 
>> doesn't match.
> PGI: Silently ignores OpenMP pragmas.
> CAPS: Ignored option '--define' (_OPENMP=).

I like how Cray handles it: It permits both - but neither OpenMP -> 
OpenACC nesting nor vice versa. (It might not always detectable.)

ERROR:
   The !$OMP PARALLEL DO directive cannot be specified within a !$ACC 
PARALLEL region.

And adding OpenACC to an OpenMP loop fails with:

ERROR:
   The !$ACC LOOP directive cannot be specified within a !$OMP PARALLEL 
DO region.

(One gets the same error independent whether one tries to place the 
pragma on the same loop or just nested in the parallel pragma or on 
different loops.)

I think doing likewise would be best. A simpler approach is to reject 
using -fopenmp and -fopenacc simultaneously.

>> b) Do you also handle DO CONCURRENT - either by rejecting it or by 
>> accepting it? Namely,
>>
>> !$acc loop
>> do concurrent(i=1:5)
>> end do
>> !$acc end loop
>> end
>> Side remark, with -fopenmp, it does ICE: 
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60127
>>
> My implemetation also fails, will fix. By the way, should we support 
> these loops? I think we should, since DO CONCURRENT loops are 
> parallelizable.

I think one should at least error out and not ICE.

The long-term solution should be to support DO CONCURRENT with both 
OpenMP and OpenACC; although one option would be to wait until the specs 
officially support it.

If you want to support it, please recall that do concurrent also permits 
a mask argument, which makes everything a bit more complicated. (Cf. 
gcc/fortran/trans-stmt.c's gfc_trans_forall_1 function.)

> No, the spec doesn't specify !$acc end loop. However, compilers handle 
> this construction differently:
> PGI: silently accepts.

Which is not surprising given that NVidia's and PGI's example often use 
"!$acc end loop". [Cray ftn also accepts it silently.]

>>> +  if (gfc_pure (NULL))
>>> +    {
>>> +      gfc_error_now ("OpenACC directives at %C may not appear in 
>>> PURE "
>>> +                     "or ELEMENTAL procedures");
...
>> In any case, either drop "or ELEMENTAL" or also check for the 
>> elemental attribute.
>>
> I think I should drop "or ELEMENTAL" since OpenMP also accepts 
> directives in IMPURE ELEMENTAL procecdures.

Fine with me.

>>> +  if (gfc_implicit_pure (NULL))
>>> +    gfc_current_ns->proc_name->attr.implicit_pure = 0;
>>
>> I believe that will fail with BLOCK - cf. gfc_implicit_pure()
> Fortunally, it doesn't.

Are you sure that it works? A block starts a new namespace, hence, 
gfc_implicit_pure() does:

----------------------cut---------------
       /* Check if the current procedure is implicit_pure.  Walk up
          the procedure list until we find a procedure.  */
       for (ns = gfc_current_ns; ns; ns = ns->parent)
         {
           sym = ns->proc_name;
           if (sym == NULL)
             return 0;

           if (sym->attr.flavor == FL_PROCEDURE)
             break;
         }
     }

   return sym->attr.flavor == FL_PROCEDURE && sym->attr.implicit_pure
     && !sym->attr.pure;
----------------------cut---------------

But you set "gfc_current_ns->proc_name->attr.implicit_pure = 0". If 
gfc_current_ns is the BLOCK, the procedure might still have the 
"implict_pure" attribute set.

Side question: Do we also need to unset implicit_pure for OpenMP?

Tobias