From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24733 invoked by alias); 7 Nov 2014 13:31:25 -0000 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 Received: (qmail 24715 invoked by uid 89); 7 Nov 2014 13:31:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients 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, 07 Nov 2014 13:31:23 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA7DVL31008902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 7 Nov 2014 08:31:21 -0500 Received: from [10.10.60.96] (vpn-60-96.rdu2.redhat.com [10.10.60.96]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sA7DVKU6002544; Fri, 7 Nov 2014 08:31:20 -0500 Message-ID: <545CC9A7.4000408@redhat.com> Date: Fri, 07 Nov 2014 13:31:00 -0000 From: Andrew MacLeod User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Andrew Haley , Richard Biener , Richard Henderson , gcc-patches CC: Jeff Law , java@gcc.gnu.org Subject: Re: [patch] Provide a can_compare_and_swap_p target hook. References: <5458FE9C.2090409@redhat.com> <54590C19.40208@redhat.com> <54591348.1010904@redhat.com> <545913A4.5010400@redhat.com> <54591B3A.8030908@redhat.com> <70044BE8-9F38-4BDB-B73F-6E2FC9AC2629@gmail.com> <54593352.2000700@redhat.com> <545BB682.9000209@redhat.com> <545BBCA5.7060203@redhat.com> <545BC666.5020007@redhat.com> <545C9176.6000006@redhat.com> In-Reply-To: <545C9176.6000006@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-11/txt/msg00005.txt.bz2 On 11/07/2014 04:31 AM, Andrew Haley wrote: > On 06/11/14 19:05, Andrew MacLeod wrote: >> >> 1) Given that the compiler *always* provides support via libatomic now >> (even if it is via locks), does that mean that VMSupportsCS8_builtin() >> should always return true? >> >> or should we map to that a call to __atomic_always_lock_free() ? (that >> always gets folded to a true or false at compile time) my guess is the >> latter? > Perhaps so. The problem is that some targets can't do CAS on 64-bit > doublewords. with libatomic present, I believe they always can, even if it drops to a lock implementation. > I'm sorry, I really can't remember. I can't think of any reason to > want to turn off builtin support. You have to remember that all this > was written when our support for atomic builtins was seriously flaky > and we would just punt back to the user anything we hadn't written > yet. > > No worries, i cant remember why i did something last year, let along 8 years ago :-) I'll take a best stab and we'll see what happens :-) Andrew