From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26801 invoked by alias); 27 Nov 2012 01:09:58 -0000 Received: (qmail 26788 invoked by uid 22791); 27 Nov 2012 01:09:57 -0000 X-SWARE-Spam-Status: No, hits=-9.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,TW_WG X-Spam-Check-By: sourceware.org Received: from g4t0016.houston.hp.com (HELO g4t0016.houston.hp.com) (15.201.24.19) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Nov 2012 01:09:52 +0000 Received: from G9W0369G.americas.hpqcorp.net (g9w0369g.houston.hp.com [16.216.193.232]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0016.houston.hp.com (Postfix) with ESMTPS id BF64214373; Tue, 27 Nov 2012 01:09:51 +0000 (UTC) Received: from G9W3613.americas.hpqcorp.net (16.216.186.48) by G9W0369G.americas.hpqcorp.net (16.216.193.232) with Microsoft SMTP Server (TLS) id 14.2.283.4; Tue, 27 Nov 2012 01:08:21 +0000 Received: from G9W0725.americas.hpqcorp.net ([169.254.8.63]) by G9W3613.americas.hpqcorp.net ([16.216.186.48]) with mapi id 14.02.0283.004; Tue, 27 Nov 2012 01:08:21 +0000 From: "Boehm, Hans" To: Bryce McKinlay , GCC Java CC: Ivan Maidanski Subject: RE: [Gc] Re: boehm-gc merge for GCC Date: Tue, 27 Nov 2012 01:09:00 -0000 Message-ID: References: <1353097280.505328435@f161.mail.ru> <50A67667.7020600@ubuntu.com> <1353099257.140499471@f123.mail.ru> <50A6EE27.4000605@ubuntu.com> <50ABADE0.9000305@redhat.com> <50B385C5.6010004@ubuntu.com> In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg00006.txt.bz2 >=20 > > - bdwgc now depends on another library (libatomic-ops). Shouldn't GCC > > be able to use it's atomic builtins for some supported targets at > > least? >=20 >=20 > Yes, but it sounds like far more effort than its worth to go and change > it > just for the sake of using builtins. Maybe libatomic-ops itself could > be > made to use the builtins when available. >=20 Libatomic_ops should eventually be configurable to just use C11/C++11 atomi= c operations. That hasn't happened yet, but should be fairly easy. Or, if= we wait long enough, we could just use the C11 primitves directly. Histor= ically libatomic-ops preceded and influenced the C11/C++11 interface, but t= he C11/C++11 interface is a much better design (another iteration, a lot mo= re careful thought by many more people, etc.) Hans