From patchwork Wed Jan 18 16:24:41 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aldy Hernandez X-Patchwork-Id: 136657 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 6E76CB6F68 for ; Thu, 19 Jan 2012 03:25:09 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1327508709; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=mCTJvKk+YvIK4097ZlV56zhwVSI=; b=l0shBIcozkIXPB5 SSH6PoIVgW2Si1bZs3LAgkXO+PbLUWkrs1XIgehk1c2GiruosudnNOrYlM9fddDc a2kpJu4X3I84XeZ5v7ZKEIwha2v4KyItypIxupjp90D+rPAkacgihEC4oUjNhb4b PkjLJbWyjsrKBBi7NXae5xQZFdPI= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=XE9KVaiNfBkCGi400+Oh/MAmuXT2sqQ2R0zsWeR0Lw0EIxA9dalI5RgjkRF58f u/0x4nEemJv4n27bPZOuYdoGcfSmlQBvvnxFSpqWxwVNXOz0jPrF5jD8pO0USZ5C LM0YBqF6dm9U8Vuudx27AENswGTjkWWoMK+8lfCISX0Lw=; Received: (qmail 22147 invoked by alias); 18 Jan 2012 16:25:02 -0000 Received: (qmail 22112 invoked by uid 22791); 18 Jan 2012 16:24:59 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, 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; Wed, 18 Jan 2012 16:24:43 +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 q0IGOhRr030941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jan 2012 11:24:43 -0500 Received: from houston.quesejoda.com (vpn-232-198.phx2.redhat.com [10.3.232.198]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q0IGOg1O000336; Wed, 18 Jan 2012 11:24:42 -0500 Message-ID: <4F16F249.9010602@redhat.com> Date: Wed, 18 Jan 2012 10:24:41 -0600 From: Aldy Hernandez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Richard Guenther CC: Patrick Marlier , GCC Patches , Diego Novillo , Richard Henderson , Torvald Riegel , Jakub Jelinek Subject: Re: [PATCH] PR51280 LTO/trans-mem ICE with TM builtins References: <4EEA5F92.1000302@gmail.com> <4EEF8CB9.4060806@gmail.com> <4F15949F.4060506@redhat.com> <4F15AE47.2040304@redhat.com> In-Reply-To: Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On 01/18/12 03:09, Richard Guenther wrote: > On Tue, 17 Jan 2012, Aldy Hernandez wrote: > >> >>>> What I have in mind is to abstract out the initialization of TM builtins >>>> from >>>> gtm-builtins.def (through its inclusion in builtins.def) into a separate >>>> function that we can call either in c_define_builtins() from the C-ish >>>> front-ends, or from lto_define_builtins (once we encounter a TM builtin >>>> and >>>> enable flag_tm appropriately). >>> >>> Hm? They are included in builtins.def, that looks appropriate for >>> middle-end builtins. Thus they should be initialized by lto1, too. >>> Are they not? >> >> Since flag_tm is NULL, when lto_define_builtins runs, the TM builtins do not >> get initialized. This is because DEF_TM_BUILTIN is predicated on flag_tm. > > Ok, so arrange that -fgnu-tm is enabled at link-time as soon as it was > enabled in one TU. You can do that alongside handling of OPT_fPIC, etc. > in lto-wrapper.c:merge_and_complain. The following patch fixes the problem. OK? >> It isn't until streamer_get_builtin_tree() that we realize the object file has >> a TM builtin. > > I see. Probably similar issues exist with -fopenmp and the GOMP > builtins. It is my understanding that openmp is lowered before LTO streaming, so this isn't a problem for it. I manually tested something similar to the testcase in the patch below (but for openmp) and verified that openmp does not suffer from this problem. Thanks for the suggestion. PR lto/51280 * lto-wrapper.c (run_gcc): Pass -fgnu_tm on. (merge_and_complain): Same. Index: testsuite/gcc.dg/lto/trans-mem-3_0.c =================================================================== --- testsuite/gcc.dg/lto/trans-mem-3_0.c (revision 0) +++ testsuite/gcc.dg/lto/trans-mem-3_0.c (revision 0) @@ -0,0 +1,8 @@ +/* { dg-lto-options {{-flto}} } */ +/* { dg-lto-do link } */ + +/* Test that we can build one object file with -fgnu-tm + (trans-mem-3_1.c), but do the final link of all objects without + -fgnu-tm. */ + +int i; Index: testsuite/gcc.dg/lto/trans-mem-3_1.c =================================================================== --- testsuite/gcc.dg/lto/trans-mem-3_1.c (revision 0) +++ testsuite/gcc.dg/lto/trans-mem-3_1.c (revision 0) @@ -0,0 +1,18 @@ +/* { dg-options "-fgnu-tm" } */ + +extern int i; + +main() +{ + __transaction_atomic { i = 0; } +} + +#define dummy(func) \ + __attribute__((noinline,noclone,used)) void func() { asm (""); } + +dummy(_ITM_beginTransaction) +dummy(_ITM_commitTransaction) +dummy(_ITM_WU4) +dummy(_ITM_WU8) +dummy(_ITM_registerTMCloneTable) +dummy(_ITM_deregisterTMCloneTable) Index: lto-wrapper.c =================================================================== --- lto-wrapper.c (revision 183244) +++ lto-wrapper.c (working copy) @@ -403,6 +403,7 @@ merge_and_complain (struct cl_decoded_op case OPT_fpie: case OPT_fcommon: case OPT_fexceptions: + case OPT_fgnu_tm: /* Do what the old LTO code did - collect exactly one option setting per OPT code, we pick the first we encounter. ??? This doesn't make too much sense, but when it doesn't @@ -555,6 +556,7 @@ run_gcc (unsigned argc, char *argv[]) case OPT_fpie: case OPT_fcommon: case OPT_fexceptions: + case OPT_fgnu_tm: break; default: