This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [OpenCoarrays] Re: Block construct and sync all behavior
- From: Damian Rouson <damian at sourceryinstitute dot org>
- To: "N.M. Maclaren" <nmm1 at cam dot ac dot uk>
- Cc: Tobias Burnus <burnus at net-b dot de>, opencoarrays at googlegroups dot com, gfortran <fortran at gcc dot gnu dot org>
- Date: Tue, 21 Oct 2014 08:54:13 -0700
- Subject: Re: [OpenCoarrays] Re: Block construct and sync all behavior
- Authentication-results: sourceware.org; auth=none
- References: <33704ECE-A5FB-4107-A708-E58725E3468D at sourceryinstitute dot org> <5445F3D9 dot 2080906 at net-b dot de> <Prayer dot 1 dot 3 dot 5 dot 1410210840140 dot 3215 at hermes-1 dot csi dot cam dot ac dot uk> <91C2BAD7-13FE-45A9-940E-FB52DDE4718C at sourceryinstitute dot org> <Prayer dot 1 dot 3 dot 5 dot 1410211646190 dot 32709 at hermes-1 dot csi dot cam dot ac dot uk>
On Oct 21, 2014, at 8:46 AM, N.M. Maclaren <nmm1@cam.ac.uk> wrote:
> On Oct 21 2014, Damian Rouson wrote:
>>
>> But, as you say, I/O synchronisation is
>>> not part of the coarray design or gfortran run-time system.
>>
>> That's fine as a design decision, but what in the standard communicates this design decision? When I read "8.5.3 SYNC ALL statement" in a draft of the Fortran 2008 standard, I see nothing that would make it clear to a novice that segment ordering does not imply ordering of I/O. It would be nice to see a note of warning.
>
> Grrk. You have a point. That is implied (vaguely) by Note 9.15, but
> doesn't seem to be stated anywhere. Nor whether the merging preserves
> record boundaries which, in practice, it won’t.
Yes, that was exactly my thought when 9.15 was mentioned. It’s not clear that a merge implies the possibility of record boundaries being reordered.
Damian