From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75820 invoked by alias); 9 Dec 2015 14:47:26 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 75800 invoked by uid 89); 9 Dec 2015 14:47:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Dec 2015 14:47:25 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 990BD483; Wed, 9 Dec 2015 06:47:00 -0800 (PST) Received: from e108033-lin.cambridge.arm.com (e108033-lin.cambridge.arm.com [10.2.206.36]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D89593F459; Wed, 9 Dec 2015 06:47:21 -0800 (PST) Subject: Re: [Fortran, Patch] Memory sync after coarray image control statements and assignment To: Tobias Burnus References: <20151207100645.GA28286@physik.fu-berlin.de> <56659312.6090700@foss.arm.com> <20151208092556.GB29964@physik.fu-berlin.de> Cc: fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org, Alessandro Fanfarillo From: Matthew Wahab Message-ID: <56683EF8.4020708@foss.arm.com> Date: Wed, 09 Dec 2015 14:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151208092556.GB29964@physik.fu-berlin.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg01007.txt.bz2 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