From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9485 invoked by alias); 11 Nov 2011 17:45:38 -0000 Received: (qmail 9469 invoked by uid 22791); 11 Nov 2011 17:45:36 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_CX X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 11 Nov 2011 17:45:20 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pABHjDXc006181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Nov 2011 12:45:14 -0500 Received: from [10.11.8.130] (vpn-8-130.rdu.redhat.com [10.11.8.130]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id pABHjBBI020269; Fri, 11 Nov 2011 12:45:12 -0500 Message-ID: <4EBD5F27.9040005@redhat.com> Date: Fri, 11 Nov 2011 17:56:00 -0000 From: Andrew MacLeod User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc13 Thunderbird/3.1.10 MIME-Version: 1.0 To: Benjamin Kosnik CC: Hans-Peter Nilsson , joseph@codesourcery.com, gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org, rth@redhat.com Subject: Re: cxx-mem-model merge [6 of 9] - libstdc++-v3 References: <201111080505.pA8553or032507@ignucius.se.axis.com> <4EB92EDD.7080709@redhat.com> <20111110214329.523635d8@shotwell> In-Reply-To: <20111110214329.523635d8@shotwell> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2011-11/txt/msg01550.txt.bz2 On 11/11/2011 12:43 AM, Benjamin Kosnik wrote: > >> bkoz: As relates to the existing problem, how is the legacy support >> invoked in compatibility-atomic-c++0x.cc? That has the old style >> implementation of atomic_flag with a lock, which would allow this >> target to compile... which is another option perhaps. or is that >> purely for pervious releases somehow? > compatibility-atomic-c++0x.cc is the support for previous builtins > attempt, let's call this atomics-try-2. We need to keep these symbols > exported and doing the same thing done in previous releases. (Or else > abi-check will fail.) > > If this system used to use a lock to work, then that is what it should > still do. The behavior shouldn't change. > I think there is also an argument for single threaded-ness vs multi threaded. If there is no atomic support and its single threaded, we don't really need the lock... and I'm not sure how you can detect the change in behaviour if test_and_set and clear just store 1 and 0 rather than create alock, then do the store of 1 or 0. If the target is multithreaded, well, we'll have to go to a lock I guess... Are there any multithreaded targets without atomic support? ie, is this one? Andrew