From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7442 invoked by alias); 11 Nov 2011 17:23:15 -0000 Received: (qmail 7424 invoked by uid 22791); 11 Nov 2011 17:23:14 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,DATE_IN_PAST_06_12,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:22:49 +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 pABHMg3v011311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Nov 2011 12:22:42 -0500 Received: from shotwell (ovpn-113-158.phx2.redhat.com [10.3.113.158]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id pABHMeLY024843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 11 Nov 2011 12:22:41 -0500 Date: Fri, 11 Nov 2011 17:49:00 -0000 From: Benjamin Kosnik To: Andrew MacLeod 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 Message-ID: <20111110214329.523635d8@shotwell> In-Reply-To: <4EB92EDD.7080709@redhat.com> References: <201111080505.pA8553or032507@ignucius.se.axis.com> <4EB92EDD.7080709@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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/msg01546.txt.bz2 > > I just realized I may be feeding you an inconsistent > > configuration, see the atomicity stuff in > > libstdc++-v3/config/cpu/cris. Is that just obsolete and unused > > now or what do I need to add for that to work? > > > > You don't need to do anything there. I think that atomicity stuff > will soon be obsolete, but bkoz will have to answer that question. > It looks to me like that was some gnu atomic extentions which predate > atomic support in the standard. In theory, that would all be able to > go away or be integrated into the gcc machine description with the > modern patterns, if its not already there. That is very obsolete and should be removed as it's now just causing confusion. That was pre-builtin days, let's call this atomics-try-1. So, all: config/cpu/*/atomicity.h ./i486/atomicity.h ./i386/atomicity.h ./sparc/atomicity.h ./sh/atomicity.h ./m68k/atomicity.h ./cris/atomicity.h ./hppa/atomicity.h ./generic/atomicity_mutex/atomicity.h ./generic/atomicity_builtins/atomicity.h ATOMICITY_SRCDIR ATOMIC_WORD_SRCDIR ATOMIC_FLAGS Should go. I'll look in to peeling off this cruft sharpish. > 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. -benjamin