From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23510 invoked by alias); 4 Nov 2011 18:42:09 -0000 Received: (qmail 23453 invoked by uid 22791); 4 Nov 2011 18:42:08 -0000 X-SWARE-Spam-Status: No, hits=-7.5 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, 04 Nov 2011 18:41:50 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pA4IfocB014720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Nov 2011 14:41:50 -0400 Received: from [10.11.10.205] (vpn-10-205.rdu.redhat.com [10.11.10.205]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id pA4IfnEt021652; Fri, 4 Nov 2011 14:41:49 -0400 Message-ID: <4EB431EC.40404@redhat.com> Date: Fri, 04 Nov 2011 18:53: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: Jeff Law CC: gcc-patches , Benjamin Kosnik Subject: Re: cxx-mem-model merge [6 of 9] - libstdc++-v3 References: <4EB328D7.9010309@redhat.com> <4EB42B8E.2010907@redhat.com> In-Reply-To: <4EB42B8E.2010907@redhat.com> 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/msg00640.txt.bz2 On 11/04/2011 02:14 PM, Jeff Law wrote: > These are the changes to libstdc++ to make use of the new atomics. >> I changed the files to use the new atomics, and bkoz did a >> shuffling of the include file layout to better suit the new c++ >> approach. >> >> previously, libstdc++ provided a locked implementation in >> atomic_0.h with the theory that eventually it would be used. The >> new scheme involves leaving non-lock-free implementations to an >> external library. This involved removing the old lock >> implementation and restructuring things now that multiple >> implementation dont have to be supported. SO a lot fo this is >> churn... 2 include files deleted and one merged into another one.. > Is there an ABI/API impact to all this churn? Or was the atomic_0.h > stuff never used? Was it an exposed API or strictly internal? I get > the impression that is_lock_free wasn't ever defined, which is > probably good in this context. > > Given these are primarily Benjamin's changes, I'm going to defer to > his wisdom :-) If he doesn't chime in, ping him directly. well, actually, the way it was setup, I don't think it was ever used. Things defaulted to using the lockfree __sync routines, and if you tried to do something that didn't map to one of those, you got either a compiler error (in the case of non-integral classes), or external __sync calls. It was in a transitional state, and never fully flushed out. At least thats was my impression when I started trying to work with it to get full support. I dont think you could trigger the code in atomic_0.h without changing the compiler/headerfiles yourself. At least I dont think so. Well, It may have been possible by explicitly specifying the __atomic0 namespace with baseclasses... Im not sure. I'll let bkoz deal with answering that :-) Since support was experimental, I dont think anyone was suppose to count on it anyway :-P I believe that any atomic integral that worked before will work today with these changes and without an external library... With the addition of the forthcoming atomic library (which is not a part of gcc) you should be able to compile and run anything, including arbitrary user PODs. WIth any luck at all, the atomic library ABI I set up is defined enough now to continue to function as is in future releases. Andrew