This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Comment 3 fixed two issues with gcc/testsuite/gfortran.dg/goacc/coarray.f95.

Still to do:

* gcc/testsuite/gfortran.dg/goacc/coarray_2.f90 contains a FIXME for a
"reduction(+:a)" variable.

For an allocatable scalar coarray, that will lead to an ICE in an assignment "a
= 0". The problem seems to relate to calling
alloc_scalar_allocatable_for_assignment from gfc_trans_assignment_1, which
shall not be called at all. (The semantics say that for coarrays those shall
always be allocated, when used and noreallocation shall be done. Coarray
(de)allocations are always colletively done across all images (= processes)).


I wonder whether there are similar other issues; the same no-realloc also
applies to allocatable array coarrays.


* One probably should check for coindexed variables (e.g. "a[i]" or
"b(1:8)[5]", where the "[...]" refers to a remote image). For everything
handled as pointer or within an offloaded region, that won't work and should be
invalid. At places where a temporary is fine, it can be used (cf. dumps with
-fcoarray=lib).

I have no idea whether there is an issue in either the OpenMP/OpenACC
directives or whether it would be testable for target/acc kernels/parallel
regions. Probably only for those declaring a procedure ("routine") to be
offloadable.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]