From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9420 invoked by alias); 29 May 2015 15:41:18 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 9403 invoked by uid 89); 29 May 2015 15:41:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_40,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 29 May 2015 15:41:17 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 1D902C2FFD; Fri, 29 May 2015 15:41:16 +0000 (UTC) Received: from anchor.twiddle.net (vpn-229-182.phx2.redhat.com [10.3.229.182]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4TFfFht024901; Fri, 29 May 2015 11:41:15 -0400 Message-ID: <55688899.1000208@redhat.com> Date: Fri, 29 May 2015 16:36:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ramana Radhakrishnan , Jason Merrill , David Edelsohn CC: "gcc-patches@gcc.gnu.org" , Jim Wilson , Steve Ellcey , Steve Munroe , Torvald Riegel Subject: Re: [RFC / CFT] PR c++/66192 - Remove TARGET_RELAXED_ORDERING and use load acquires. References: <555F1143.4070606@foss.arm.com> <555F11B6.1070001@foss.arm.com> <555F31CF.6060201@redhat.com> <555F3D09.2070700@redhat.com> <555F49FF.1070402@foss.arm.com> <555F6911.6030205@redhat.com> <5568673A.6060007@foss.arm.com> In-Reply-To: <5568673A.6060007@foss.arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg02801.txt.bz2 On 05/29/2015 06:18 AM, Ramana Radhakrishnan wrote: > > One of the bits of fallout that I've observed in my testing and that I'm not > sure about what to do is that on *bare-metal* arm-none-eabi targets we still > put out calls to __sync_synchronize on architecture versions that do not have a > barrier instruction which will result in a link error. > > While it is tempting to take the easy approach of not putting out the call, I > suspect in practice a number of users of the bare-metal tools use these for > their own RTOS's and other micro-OS's. Thus generating barriers at higher > architecture levels and not generating barriers at lower architecture levels > appears to be a bit dangerous especially on architectures where there is > backwards compatibility (i.e. -mcpu=arm7tdmi on standard user code is still > expected to generate code that works on a core that conforms to a later > architecture revision). > > I am considering leaving this in the ARM backend to force people to think what > they want to do about thread safety with statics and C++ on bare-metal systems. > If they really do not want thread safety they can well add > -fno-threadsafe-statics or provide an appropriate implementation for > __sync_synchronize on their platforms. > > Any thoughts / comments ? That seems reasonable. It probably warrants some documentation somewhere though. r~