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

[Ilmir Usmanov <i dot usmanov at samsung dot com>]

Hi Tobias!

Thanks a lot for your review!

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

If I made a mistake and you've collected results which differ from mine 
(whether you compiler is one of the above or not), please, let me know.

Unfortunally, neither PGI nor CAPS don't support Fortran 2008.

These are results:

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=).

> 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.

> Talking about "!$acc loop": I vaguely remember that OpenACC 1.0's spec 
> doesn't have "!$acc end loop" while I have seen OpenACC programs which 
> use it. How do you handle "!$acc end loop"?
> Looking at parse.c, it seems to simply error out. I wonder whether one 
> should be a bit more graceful. For instance, the following examples 
> use "!$acc end loop": 
> http://devblogs.nvidia.com/parallelforall/openacc-example-part-2/ [If 
> I remember correctly, pgf95 and Cray ftn silently accepts "end loop" 
> while pathf95 accepts it with a warning.]
>
> And looking at the spec of OpenACC 1.0 and 2.0a, the "end loop" seems 
> to be invalid. How about following PathScale's ENZO and accepting "end 
> loop" with a warning? Or at least error out with a good error message.
No, the spec doesn't specify !$acc end loop. However, compilers handle 
this construction differently:
PGI: silently accepts.
CAPS: Syntax error: expecting ('parallel' ('loop' or end)) or 
(('kernels' or 'dfkernels') ('loop' or end)) or 'data' or 'host_data'
!$acc  end loop
My implementation also errors out, but I agree, we should accept this 
with warning.

> > +  if (gfc_pure (NULL))
> > +    {
> > +      gfc_error_now ("OpenACC directives at %C may not appear in PURE "
> > +                     "or ELEMENTAL procedures");
>
> Using gfc_pure() you do not check for ELEMENTAL: Since Fortran 2008, 
> there are also IMPURE ELEMENTAL procedures. I don't know the spec, but 
> I don't really see a reason why OpenACC shouldn't be permitted in 
> IMPURE ELEMENTAL procedures. (BTW: "ELEMENTAL" implies PURE unless an 
> explicit IMPURE is used.)
>
> 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.

> > +  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()
>
> real function foo(n)
>   integer, value :: n
>   BLOCK
>      integer i
>      real sum
>      !$acc loop reduce(+:sum)
>      do i=1, n
>         sum += sin(real(i))
>      end do
>   END BLOCK
> end
Fortunally, it doesn't.

--
Ilmir.