[Bug fortran/63861] New: OpenACC coarray ICE

[Bug fortran/63861] New: OpenACC coarray ICE

[cesar at codesourcery dot com]

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

            Bug ID: 63861
           Summary: OpenACC coarray ICE
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: cesar at codesourcery dot com

Coarrays in OpenACC accelerated regions causes an ICE in gfortran. The test
case gcc/testsuite/gfortran.dg/goacc/coarray.f95 reproduces this failure. It's
unclear whether OpenACC 2.0a even supports coarrays. Regardless, this test case
shouldn't cause an ICE.

[Bug fortran/63861] OpenACC coarray ICE

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Cesar Philippidis from comment #0)
> Coarrays in OpenACC accelerated regions causes an ICE in gfortran. The test
> case gcc/testsuite/gfortran.dg/goacc/coarray.f95 reproduces this failure.

It already ICEs for me with a normal variable: PR64726, besides it currently
doesn't ICE because CACHE is not yet implemented: PR63865.

Note that the test case should at the end also use -fcoarray=lib besides
-fcoarray=single.


> It's unclear whether OpenACC 2.0a even supports coarrays. Regardless, this
> test case shouldn't cause an ICE.

Regarding coarrays: If they are not coindexed ("a[remote_process_idx]"), they
act as local variable. Thus, I'd expect that they work. Synchronization is in
the realm of the user, who has to ensure that the host has the current value
and the processes are sync'ed when remote access is required. [One probably
should also reject calls to a procedures which expect a coarray as argument as
that won't fly either. That's something to be done on best-effort base.]

Thus, I think they should be permitted.

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

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |openmp
            Summary|OpenACC coarray ICE         |OpenACC coarray ICE  (also
                   |                            |with OpenMP?)

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
With the patch for PR64726 applied and the ACC CACHE commented, the program
gets stuck (endless loop) for the code in
gcc/testsuite/gfortran.dg/goacc/coarray.f95.

It works, if one changes the scalar coarray into either an array coarray or
into a noncoarray scalar.

I think gfc_has_alloc_comps just needs to be updated to handle coarrays, which
use an array descriptor but aren't true arrays. (I think
GFC_TYPE_ARRAY_RANK(...) == 0 can be used to detect this, but that might not
work for all array types.)


I marked it as "OpenMP" as it is probably also possible to trigger this for
some OpenMP code. Even though, I do not have a test case.


Backtrace:

#1  gfc_get_element_type (type=0x7ffff20f25e8) at
../../gcc/fortran/trans-types.c:1180
#2  0x0000000000742f85 in gfc_has_alloc_comps (type=<optimized out>,
decl=<optimized out>) at ../../gcc/fortran/trans-openmp.c:193
#3  0x000000000099eb12 in gimplify_scan_omp_clauses (list_p=0x7ffff20f32a0,
pre_p=pre_p@entry=0x7fffffffd918, region_type=region_type@entry=ORT_TARGET) at
../../gcc/gimplify.c:6062
#4  0x00000000009a07c8 in gimplify_omp_workshare
(expr_p=expr_p@entry=0x7ffff20eb778, pre_p=pre_p@entry=0x7fffffffd918) at
../../gcc/gimplify.c:7307

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

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Tue Jan 27 19:57:55 2015
New Revision: 220189

URL: https://gcc.gnu.org/viewcvs?rev=220189&root=gcc&view=rev
Log:
2015-01-27  Tobias Burnus  <burnus@net-b.de>

        PR fortran/63861
gcc/fortran/
        * trans-openmp.c (gfc_has_alloc_comps, gfc_trans_omp_clauses):
        Fix handling for scalar coarrays.
        * trans-types.c (gfc_get_element_type): Add comment.
gcc/testsuite/
        * gfortran.dg/goacc/coarray_2.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/goacc/coarray_2.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-openmp.c
    trunk/gcc/fortran/trans-types.c
    trunk/gcc/testsuite/ChangeLog

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

[burnus at gcc dot gnu.org]

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.

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2015-10-20
     Ever confirmed|0                           |1

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Is this fixed after r220189?

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

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
                 CC|                            |tschwinge at gcc dot gnu.org

--- Comment #6 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #5)
> Is this fixed after r220189?

No.