From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7342 invoked by alias); 3 Oct 2011 13:22:22 -0000 Received: (qmail 7333 invoked by uid 22791); 3 Oct 2011 13:22:21 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,TW_DM X-Spam-Check-By: sourceware.org Received: from mail-dy0-f47.google.com (HELO mail-dy0-f47.google.com) (209.85.220.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Oct 2011 13:21:55 +0000 Received: by dyk17 with SMTP id 17so84142dyk.20 for ; Mon, 03 Oct 2011 06:21:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.54.202 with SMTP id r10mr8856034fag.114.1317648114019; Mon, 03 Oct 2011 06:21:54 -0700 (PDT) Received: by 10.152.41.2 with HTTP; Mon, 3 Oct 2011 06:21:53 -0700 (PDT) In-Reply-To: References: <20110701155254.GA5242@davesworkthinkpad> <20110726085910.GA6925@davesworkthinkpad> <20110726090039.GB6925@davesworkthinkpad> <20110726090115.GC6925@davesworkthinkpad> Date: Mon, 03 Oct 2011 13:22:00 -0000 Message-ID: Subject: Re: [Patch 2/4] ARM 64 bit sync atomic operations [V2] From: David Gilbert To: "H.J. Lu" Cc: Ramana Radhakrishnan , gcc-patches@gcc.gnu.org, rth@redhat.com, joseph@codesourcery.com, patches@linaro.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes 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 X-SW-Source: 2011-10/txt/msg00082.txt.bz2 On 30 September 2011 18:01, H.J. Lu wrote: > You may want to look a look at: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50583 > > ARM may have the same problem. OK - although to be honest this patch only stretches the same structures to 64bit - any major changes in semantics are a separate issue - but thanks for pointing it out. Hmm - I think what's produced is correct; however the manual description is inconsistent: These builtins perform the operation suggested by the name, and returns the value that had previously been in memory. That is, { tmp = *ptr; *ptr OP= value; return tmp; } The ARM code (see below) does a single load inside a loop with a guarded store. This guarantees that the value returned is the value that was 'previously been in memory' directly prior to the atomic operation - however that does mean it doesn't do the pair of accesses implied by the 'tmp = *ptr; *ptr OP= value' On ARM the operation for fetch_and_add we get: (This is pre-my-patch and 32bit, my patch doesn't change the structure except for the position of that last label): mov r3, r0 dmb sy .LSYT6: ldrex r0, [r3] add r2, r0, r1 strex r0, r2, [r3] teq r0, #0 bne .LSYT6 sub r0, r2, r1 dmb sy That seems the correct semantics to me - if not what am I missing? Was the intention of the example really to cause two loads - if so why? for sync_and_fetch we get: dmb sy .LSYT6: ldrex r0, [r3] add r0, r0, r1 strex r2, r0, [r3] teq r2, #0 bne .LSYT6 dmb sy i.e. the value returned is always the value that goes into the guarded store - and is hence always the value that's stored. Dave