From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-311636-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 13309 invoked by alias); 19 Jan 2012 09:14:02 -0000
Received: (qmail 13271 invoked by uid 22791); 19 Jan 2012 09:14:01 -0000
X-SWARE-Spam-Status: No, hits=-3.2 required=5.0	tests=AWL,BAYES_00,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Jan 2012 09:13:38 +0000
Received: from relay2.suse.de (unknown [195.135.220.254])	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))	(No client certificate requested)	by mx2.suse.de (Postfix) with ESMTP id D5F218FFDD;	Thu, 19 Jan 2012 10:13:36 +0100 (CET)
Date: Thu, 19 Jan 2012 09:14:00 -0000
From: Richard Guenther <rguenther@suse.de>
To: Aldy Hernandez <aldyh@redhat.com>
Cc: Patrick Marlier <patrick.marlier@gmail.com>,	GCC Patches <gcc-patches@gcc.gnu.org>,	Diego Novillo <dnovillo@google.com>,	Richard Henderson <rth@redhat.com>,	Torvald Riegel <triegel@redhat.com>, Jakub Jelinek <jakub@redhat.com>
Subject: Re: [PATCH] PR51280 LTO/trans-mem ICE with TM builtins
In-Reply-To: <4F16F249.9010602@redhat.com>
Message-ID: <alpine.LNX.2.00.1201191013220.4999@zhemvz.fhfr.qr>
References: <4EEA5F92.1000302@gmail.com> <alpine.LNX.2.00.1112160954030.4527@zhemvz.fhfr.qr> <4EEF8CB9.4060806@gmail.com> <alpine.LNX.2.00.1112201042350.4999@zhemvz.fhfr.qr> <4F15949F.4060506@redhat.com> <alpine.LNX.2.00.1201171645050.4999@zhemvz.fhfr.qr> <4F15AE47.2040304@redhat.com> <alpine.LNX.2.00.1201181005320.4999@zhemvz.fhfr.qr> <4F16F249.9010602@redhat.com>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2012-01/txt/msg00947.txt.bz2

On Wed, 18 Jan 2012, Aldy Hernandez wrote:

> 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?

Ok.

Thanks,
Richard.