From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15363 invoked by alias); 30 Jun 2011 14:59:40 -0000 Received: (qmail 15352 invoked by uid 22791); 30 Jun 2011 14:59:39 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_TX,T_RP_MATCHES_RCVD 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; Thu, 30 Jun 2011 14:59:23 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p5UExNQs005565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 30 Jun 2011 10:59:23 -0400 Received: from anchor.twiddle.net (vpn-224-214.phx2.redhat.com [10.3.224.214]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p5UExMIt016437; Thu, 30 Jun 2011 10:59:23 -0400 Message-ID: <4E0C8F4A.6000503@redhat.com> Date: Thu, 30 Jun 2011 15:03:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10 MIME-Version: 1.0 To: Torvald Riegel CC: GCC Patches Subject: Re: [trans-mem] Beginning of refactoring References: <1306357828.13348.423.camel@triegel.csb> <4E0BAED2.3030108@redhat.com> <1309432557.3609.798.camel@triegel.csb> In-Reply-To: <1309432557.3609.798.camel@triegel.csb> Content-Type: text/plain; charset=UTF-8 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-06/txt/msg02361.txt.bz2 On 06/30/2011 04:15 AM, Torvald Riegel wrote: > On Wed, 2011-06-29 at 16:01 -0700, Richard Henderson wrote: >> On 05/25/2011 02:10 PM, Torvald Riegel wrote: >>> Patch 2: _ITM_dropReferences is not sufficiently defined in the ABI. It >>> seems to target some form of open nesting for txnal wrappers, but the >>> prose in the ABI specification is unclear. Thus, disable this for now >>> (aka fatal runtime error), and expect the related tests to fail. Pick it >>> up again once that the ABI has been improved and the use cases are >>> clear. >> >> Sure, but please actually delete the code rather than just comment it out. > > Fixed in updated patch2. This patch is ok. > How it works is that in a TM-method-specific dispatch class we would add > CREATE_DISPATCH_METHODS(static, _static) > in addition to the > CREATE_DISPATCH_METHODS(virtual, ) > that is currently there. In barrier.cc we can then do > CREATE_DISPATCH_FUNCTIONS(GTM::serial_dispatch::_, _static) > and thus bypass the virtual functions, but still keep one implementation > of the TM method (in the static template functions). This example would > create functions that just use the serial-mode accesses. Ah yes, I remember discussing this. > The trailing underscore at the end of the first param is to make the > preprocessor happen. Is there a better way to let it accept > "GTM::abi_disp()->" as argument? It depends on what else you're passing to the other methods above. It does seem odd, though, that you're passing some bit of global state to the virtual dispatch methods (the result of abi_disp()) whereas you're arranging to pass nothing but a name concatenation to the others. I'm not sure what to make of your first two examples above, but let's suppose that the third example is the real one. In which case you don't actually need concatenation. Remove the ## from the macro and then you can pass in GTM::abi_disp()-> and GTM::serial_dispatch:: which require no more than adjacency. >> Why? We're already in a header that's clearly marked "internal". > > I moved these macros to a common header so libitm_i.h doesn't have to be > included everywhere. There was some circular dependency after the > changes (I think in via the barrier definitions for SSE etc.). What's > the issue that you see with this change? Not really an issue, it just seemed odd. > Are the attached updated patches okay for the branch? Yeah, we can iterate on the points above without re-sending the entire patch3 again. r~