From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-170170-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 20047 invoked by alias); 12 Sep 2011 07:03:05 -0000
Received: (qmail 20038 invoked by uid 22791); 12 Sep 2011 07:03:03 -0000
X-SWARE-Spam-Status: No, hits=-2.4 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW
X-Spam-Check-By: sourceware.org
Received: from mail-vx0-f175.google.com (HELO mail-vx0-f175.google.com) (209.85.220.175)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 12 Sep 2011 07:02:47 +0000
Received: by vxh2 with SMTP id 2so1848226vxh.20        for <gcc@gcc.gnu.org>; Mon, 12 Sep 2011 00:02:46 -0700 (PDT)
Received: by 10.52.26.109 with SMTP id k13mr1754934vdg.192.1315810966393;        Mon, 12 Sep 2011 00:02:46 -0700 (PDT)
Received: from yakj.usersys.redhat.com (93-34-199-31.ip51.fastwebnet.it [93.34.199.31])        by mx.google.com with ESMTPS id jz10sm9239677vdb.14.2011.09.12.00.02.42        (version=TLSv1/SSLv3 cipher=OTHER);        Mon, 12 Sep 2011 00:02:44 -0700 (PDT)
Message-ID: <4E6DAE90.3070202@gnu.org>
Date: Mon, 12 Sep 2011 07:03:00 -0000
From: Paolo Bonzini <bonzini@gnu.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2
MIME-Version: 1.0
To: Geert Bosch <bosch@adacore.com>
CC: Andrew MacLeod <amacleod@redhat.com>,  Jakub Jelinek <jakub@redhat.com>, GCC Mailing List <gcc@gcc.gnu.org>, Aldy Hernandez <aldyh@redhat.com>
Subject: Re: should sync builtins be full optimization barriers?
References: <4E69C942.3090808@gnu.org> <20110909081705.GT2687@tyan-ft48-01.lab.bos.redhat.com> <5F13A1A0-79E5-4733-B543-4A6F6311A247@adacore.com> <4E6CC1E4.5000000@redhat.com> <93C7346D-DC47-4C6B-9755-EF438D82DDEA@adacore.com>
In-Reply-To: <93C7346D-DC47-4C6B-9755-EF438D82DDEA@adacore.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2011-09/txt/msg00118.txt.bz2

On 09/11/2011 09:00 PM, Geert Bosch wrote:
> So, if I understand correctly, then operations using relaxed memory
> order will still need fences, but indeed do not require any
> optimization barrier. For memory_order_seq_cst we'll need a full
> barrier, and for the others there is a partial barrier.

If you do not need an optimization barrier, you do not need a processor 
barrier either, and vice versa.  Optimizations are just another factor 
that can lead to reordered loads and stores.

Paolo