From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24308 invoked by alias); 22 Jun 2011 16:40:45 -0000 Received: (qmail 24298 invoked by uid 22791); 22 Jun 2011 16:40:44 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Jun 2011 16:40:30 +0000 From: "david.gilbert at linaro dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/48126] arm_output_sync_loop: misplaced memory barrier, missing clrex / dummy strex X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: david.gilbert at linaro dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Wed, 22 Jun 2011 16:40:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg01981.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48126 Dr. David Alan Gilbert changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david.gilbert at linaro dot | |org --- Comment #5 from Dr. David Alan Gilbert 2011-06-22 16:40:07 UTC --- Michael: I think I agree with you on the need for the barrier in the branch out case; gcc's info page (section 6.49 'Built-in functions for atomic memory access') state: ----- In most cases, these builtins are considered a "full barrier". That is, no memory operand will be moved across the operation, either forward or backward. Further, instructions will be issued as necessary to prevent the processor from speculating loads across the operation and from queuing stores after the operation. ------ so it does look like that last barrier would be needed to stop a subsequent load floating backwards before the ldrex. If I understand correctly however most cases wouldn't need it - I think most cases are use the compare&swap to take some form of lock, and then once you know you have the lock go and do your accesses - and in that case the ordering is guaranteed, where as if you couldn't take the lock you wouldn't use the subsequent access anyway. Dave