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.

Reply via email to