From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-195366-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 42204 invoked by alias); 27 Feb 2018 10:40:54 -0000
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
Received: (qmail 42194 invoked by uid 89); 27 Feb 2018 10:40:54 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*i:sk:t3sGPjN, H*i:CAJA7tRZwa8L, H*f:sk:t3sGPjN, H*f:CAJA7tRZwa8L
X-HELO: mx1.redhat.com
Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Feb 2018 10:40:53 +0000
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6])	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))	(No client certificate requested)	by mx1.redhat.com (Postfix) with ESMTPS id D303140FB647;	Tue, 27 Feb 2018 10:40:41 +0000 (UTC)
Received: from ovpn-118-0.ams2.redhat.com (unknown [10.36.118.0])	by smtp.corp.redhat.com (Postfix) with ESMTPS id BD320213AEF5;	Tue, 27 Feb 2018 10:40:40 +0000 (UTC)
Message-ID: <1519728038.15077.718.camel@redhat.com>
Subject: Re: Fw: GCC interpretation of C11 atomics (DR 459)
From: Torvald Riegel <triegel@redhat.com>
To: Ramana Radhakrishnan <ramana.gcc@googlemail.com>
Cc: Ruslan Nikolaev <nruslan_devel@yahoo.com>, Alexander Monakov	 <amonakov@ispras.ru>, Florian Weimer <fweimer@redhat.com>, Szabolcs Nagy	 <szabolcs.nagy@arm.com>, GCC Patches <gcc@gcc.gnu.org>
Date: Tue, 27 Feb 2018 11:14:00 -0000
In-Reply-To: <CAJA7tRZwa8L++t3sGPjNikP_z1homN6YPeQbkfGy86OUCgx9TQ@mail.gmail.com>
References: <1615980330.4453149.1519617655582.ref@mail.yahoo.com>	 <1615980330.4453149.1519617655582@mail.yahoo.com>	 <alpine.LNX.2.20.13.1802260817550.8765@monopod.intra.ispras.ru>	 <108651736.4493788.1519629845236@mail.yahoo.com>	 <1519672046.15077.675.camel@redhat.com>	 <1175928742.4904141.1519673957549@mail.yahoo.com>	 <487848793.5030239.1519685142961@mail.yahoo.com>	 <CAJA7tRZwa8L++t3sGPjNikP_z1homN6YPeQbkfGy86OUCgx9TQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
X-SW-Source: 2018-02/txt/msg00224.txt.bz2

On Tue, 2018-02-27 at 10:22 +0000, Ramana Radhakrishnan wrote:
> The way to fix this in AArch64 if there is a
> guarantee from the standard that there are no  problems with read-only
> locations is to implement the change in libatomic.

Even though the standard doesn't specify read-only memory, I think that
consensus in ISO C++ SG1 (ie, the concurrency study group) exists that
it makes sense for implementations to not declare something lock-free if
the hardware doesn't provide a true atomic load for the particular
size/alignment.  It is an implementation-level decision though (given
that the details of the as-if rule depend on what's doable on the
particular implementation), and I do not see a reason to change GCC's
stance on this.