[Fortran, Patch] Memory sync after coarray image control statements and assignment

[Matthew Wahab]

On 08/12/15 09:25, Tobias Burnus wrote:
> On Mon, Dec 07, 2015 at 02:09:22PM +0000, Matthew Wahab wrote:
>>>> I wonder whether using
>>>> __asm__ __volatile__ ("":::"memory");
>>>> would be sufficient as it has a way lower overhead than
>>>> __sync_synchronize().
>>
>> I don't know anything about Fortran or coarrays and I'm curious
>> whether this affects architectures with weak memory models. Is the
>> barrier only needed to stop reordering by the compiler or is does it
>> also need to stop reordering by the hardware?
>
> Short answer: I think no mfence is needed as either the communication
> is local (to the thread/process) - in which case the hardware will act
> correctly - or the communication is remote (different thread, process,
> communication to different computer via interlink [ethernet, infiniband,
> ...]); and in the later case, the communication library has to deal with
> it.

Thanks for explaining this, it made things clear. Based on your description, I agree 
that hardware reordering shouldn't be a problem.

> and the (main) program code (slightly trimmed):
>
>    static void * restrict caf_token.0;
>    static integer(kind=4) * restrict var;
>    void _caf_init.1 (void);
>
>    *var = 4;
>
>    desc.3.data = 42;
>    _gfortran_caf_send (caf_token.0, 0B /* offset */ var,
>                        _gfortran_caf_this_image (0), &desc.2, 0B, &desc.3, 4, 4, 0);
>    __asm__ __volatile__("":::"memory");  // new
>    tmp = *var;
>
> The problem is that in that case the compiler does not know that
> "_gfortran_caf_send (caf_token.0," can modify "*var".
>

Is the restrict attribute on var correct? From what you say, it sounds like *var 
could be accessed through other pointers (assuming restrict has the same meaning as 
in C).

Matthew