From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116901 invoked by alias); 27 Feb 2018 13:16:25 -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 116892 invoked by uid 89); 27 Feb 2018 13:16:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*c:PHrt, H*f:sk:4b2ab13, H*i:sk:4b2ab13, Hx-languages-length:2191 X-HELO: sonic301-21.consmr.mail.gq1.yahoo.com Received: from sonic301-21.consmr.mail.gq1.yahoo.com (HELO sonic301-21.consmr.mail.gq1.yahoo.com) (98.137.64.147) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Feb 2018 13:16:19 +0000 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 27 Feb 2018 13:16:17 +0000 Date: Tue, 27 Feb 2018 13:17:00 -0000 From: "Ruslan Nikolaev via gcc" Reply-To: Ruslan Nikolaev Reply-To: Ruslan Nikolaev To: Szabolcs Nagy , Torvald Riegel Cc: "nd@arm.com" , Alexander Monakov , Florian Weimer , "gcc@gcc.gnu.org" Message-ID: <1374244604.4526352.1519737372145@mail.yahoo.com> In-Reply-To: <4b2ab132-63e7-ce20-90e0-58632c60e07a@arm.com> References: <1615980330.4453149.1519617655582.ref@mail.yahoo.com> <1615980330.4453149.1519617655582@mail.yahoo.com> <108651736.4493788.1519629845236@mail.yahoo.com> <1519672046.15077.675.camel@redhat.com> <1175928742.4904141.1519673957549@mail.yahoo.com> <487848793.5030239.1519685142961@mail.yahoo.com> <1519730046.15077.736.camel@redhat.com> <1425399437.5330155.1519736166191@mail.yahoo.com> <4b2ab132-63e7-ce20-90e0-58632c60e07a@arm.com> Subject: Re: Fw: GCC interpretation of C11 atomics (DR 459) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00232.txt.bz2 > 1) your proposal would make gcc non-conforming to iso c unless it changes how static const objects are emitted. I do not think, ISO C requires to put const objects to .rodata. And it is easily solved by not placing it there for _Atomic objects that cannot be safely loaded from read-only memory. > 2) the two implementations are not abi compatible, the choice is already made, changing it is an abi break. Since current implementations redirects to libatomic anyway, almost nothing should break. The only case it will break -- if somebody erroneously used atomic_load for 128-bit type on read-only memory (which is, again, not guaranteed by the standard). In practice, this case almost non-existent. The worst that may happen -- you will a segfault right away. > 3) Torvald pointed out further considerations such as users expecting lock-free atomic loads to be faster than stores. Is it even true? Is it faster to use some global lock (implemented through RMW) than a single RMW operation? If you use this global lock, you will not get loads faster than stores.