From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128950 invoked by alias); 26 Feb 2018 14:53:30 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 128098 invoked by uid 89); 26 Feb 2018 14:53:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Hx-languages-length:3013, H*c:PHrt, H*c:alternative, H*x:5.0 X-HELO: sonic304-22.consmr.mail.gq1.yahoo.com Received: from sonic304-22.consmr.mail.gq1.yahoo.com (HELO sonic304-22.consmr.mail.gq1.yahoo.com) (98.137.68.203) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Feb 2018 14:53:28 +0000 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Mon, 26 Feb 2018 14:53:27 +0000 Date: Mon, 26 Feb 2018 14:53:00 -0000 From: "Ruslan Nikolaev via gcc" Reply-To: Ruslan Nikolaev Reply-To: Ruslan Nikolaev To: Alexander Monakov , Szabolcs Nagy Cc: "gcc@gcc.gnu.org" , "nd@arm.com" Message-ID: <1335826786.4690119.1519656803674@mail.yahoo.com> In-Reply-To: References: <1615980330.4453149.1519617655582.ref@mail.yahoo.com> <1615980330.4453149.1519617655582@mail.yahoo.com> Subject: Re: GCC interpretation of C11 atomics (DR 459) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00197.txt.bz2 Thank you for more comments, my response is below. On Mon, 26 Feb 2018, Szabolcs Nagy wrote:>=20 > rmw load is only valid if the implementation can > guarantee that atomic objects are never read-only. But per response from WG14 regarding DR 459 which I quoted, the standard do= es not seem to define behavior for read-only memory (and const qualifier sh= ould not suggest that). RMW, according to them, is fine for atomic_load. > current implementations on linux (including clang) > don't do that, so an rmw load can observably break > conforming c code: a static global const object is > placed in .rodata section and thus rmw on it is a > crash at runtime contrary to c standard requirements. I have just tried to compile the code using clang. Latest stable version of= clang seems to emit cmpxchg16b for the code you mentioned if I specify mcx= 16. If I do not, it redirects to libatomic.=C2=A0 (I have not tried the ver= sion from the trunk, though.) On Monday, February 26, 2018 8:57 AM, Alexander Monakov wrote: > OK, but that sounds like a matter of not emitting atomic > objects into .rodata, which shouldn't be a big problem, > if not for backwards compatibility concern? I agree, sounds like a good idea. Certainly for _Atomic objects > 8 bytes. > and then with new enough libatomic on Glibc this segfaults > with GCC on x86_64 too due to IFUNC redirection mentioned > in the other subthread. Seems like it is a problem anyway. Another reason to never emit _Atomic ins= ide .rodata =20=20=20