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.
