[Bug fortran/53526] New: [Coarray] (lib) Properly handle MOVE_ALLOC for coarrays

[Bug fortran/53526] New: [Coarray] (lib) Properly handle MOVE_ALLOC for coarrays

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53526

             Bug #: 53526
           Summary: [Coarray] (lib) Properly handle MOVE_ALLOC for
                    coarrays
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org


MOVE_ALLOC needs to be properly handled for coarrays.

Cf. F08/0040 at http://j3-fortran.org/doc/year/12/12-006A.txt
and http://j3-fortran.org/pipermail/j3/2012-May/005310.html
and http://gcc.gnu.org/ml/fortran/2012-05/msg00156.html
and http://gcc.gnu.org/ml/fortran/2012-05/msg00166.html


TODO:
- Check whether an (implied) SYNC ALL has to be inserted
  -> The main issue is probably the deallocation of TO;
  probably no extra care is required, except to ensure that
  the deallocation is properly done.

- Check whether the "token" is correctly transferred

- Check whether some library action is required.
  -> Probably not.

>From F08/0040:

  QUESTION:

    Was it intended that MOVE_ALLOC be applicable to coarrays?

  ANSWER:

    Yes.  A call to MOVE_ALLOC on coarrays might involve the deallocation
    of a coarray, therefore MOVE_ALLOC needs to be an image control
    statement.

    Also, the corank of FROM and TO needs to be the same.

[Bug fortran/53526] [Coarray] (lib) Properly handle MOVE_ALLOC for coarrays

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53526

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> 2012-05-30 10:10:34 UTC ---
Extra TODO:

Check whether the library has/should have a short cut for DEALLOCATE if the
memory is NULL. The free() might be still required (to avoid valgrind warnings,
cf. PR 53521) as might be the SYNC ALL to ensure code of the following kind
works:

  if (this_image() == 2) &
    A[1] = 5
  call move_alloc(...)
  if (this_image() == 1) &
    print *, A

[Bug fortran/53526] [Coarray] (lib) Properly handle MOVE_ALLOC for coarrays

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53526

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-06-01 17:54:42 UTC ---
MOVE_ALLOC - following the current interpretation request - seems to be more
complicated that I had imagined:

It's unclear to me whether the users have to invoke it on all images (like
allocate/deallocate) or not. If not, one gets into all kind of issues. See:
http://j3-fortran.org/pipermail/j3/2012-June/005312.html

Assuming that the user has to call it on all images, the current patches are:
- check.c: http://gcc.gnu.org/ml/fortran/2012-05/msg00171.html
- trans-intrinsic.c: http://gcc.gnu.org/ml/fortran/2012-05/msg00173.html

In the latter, the SYNC ALL should be replaced by SYNC MEMORY, which is all
what is implied by an image control statement. (It cannot be nothing as some
changes before MOVE_ALLOC might have to be flushed.) Or might might remain SYNC
ALL - which is required to avoid inconsistency issues [assuming that it has to
be called on all images].

[Bug fortran/53526] [Coarray] (lib) Properly handle MOVE_ALLOC for coarrays

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53526

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-06-06 15:34:23 UTC ---
*** Bug 45602 has been marked as a duplicate of this bug. ***

[Bug fortran/53526] [Coarray] (lib) Properly handle MOVE_ALLOC for coarrays

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53526

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-06-18 18:14:11 UTC ---
Author: burnus
Date: Mon Jun 18 18:14:06 2012
New Revision: 188747

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188747
Log:
2012-06-18  Tobias Burnus  <burnus@net-b.de>

        PR fortran/53526
        * check.c (gfc_check_move_alloc): Reject coindexed actual
        * arguments
        and those with different corank.

2012-06-18  Tobias Burnus  <burnus@net-b.de>

        PR fortran/53526
        * gfortran.dg/coarray_27.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/coarray_27.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/check.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/53526] [Coarray] (lib) Properly handle MOVE_ALLOC for coarrays

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53526

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-06-18 18:15:56 UTC ---
Author: burnus
Date: Mon Jun 18 18:15:51 2012
New Revision: 188748

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188748
Log:
2012-06-18  Tobias Burnus  <burnus@net-b.de>

        PR fortran/53526
        * trans-intrinsic.c (conv_intrinsic_move_alloc): Handle
        * coarrays.

2012-06-18  Tobias Burnus  <burnus@net-b.de>

        PR fortran/53526
        * gfortran.dg/coarray_lib_move_alloc_1.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/coarray/move_alloc_1.f90
    trunk/gcc/testsuite/gfortran.dg/coarray_lib_move_alloc_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-intrinsic.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/53526] [Coarray] (lib) Properly handle MOVE_ALLOC for coarrays

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53526

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-06-18 18:31:21 UTC ---
Seemingly, I was wrongly claiming that J3 passed the current text: It passed a
J3 meeting but not the email ballot. The latter is currently underway and two
of the votes were "N" with the comment that MOVE_ALLOC should act similar to
ALLOCATE by creating a global barrier. Namely:
http://j3-fortran.org/pipermail/j3/2012-June/005317.html
http://j3-fortran.org/pipermail/j3/2012-June/005318.html

As that's what is implemented in gfortran and as it makes sense, I close this
PR as FIXED.