From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25458 invoked by alias); 8 Sep 2009 16:04:32 -0000 Received: (qmail 25350 invoked by uid 22791); 8 Sep 2009 16:04:31 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI X-Spam-Check-By: sourceware.org Received: from cantor.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Sep 2009 16:04:23 +0000 Received: from relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 6ED2F90975; Tue, 8 Sep 2009 18:04:20 +0200 (CEST) Date: Tue, 08 Sep 2009 16:04:00 -0000 From: Richard Guenther To: Richard Henderson Cc: gcc-patches@gcc.gnu.org, Diego Novillo Subject: Re: [PATCH] Merge from LTO: eh_personality changes In-Reply-To: <4AA67CD1.8020602@redhat.com> Message-ID: References: <4AA293E4.8090301@redhat.com> <4AA2A9D7.3030406@redhat.com> <4AA67CD1.8020602@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: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2009-09/txt/msg00535.txt.bz2 On Tue, 8 Sep 2009, Richard Henderson wrote: > On 09/08/2009 05:37 AM, Richard Guenther wrote: > > Hmm, ok. So how about setting DECL_EH_PERSONALITY during eh-lowering > > and only for functions with a non-empty EH tree. We then would > > disallow inlining functions with different non-NULL personality. > > I suppose we could do better than that -- only record the > personality if there are runtime types involved. So that Yeah, something for further enhancement. > if there are only cleanups we don't prevent merging. And > if we get to the end and find personality is still unset, > then we can use the default C personality from libgcc. Or none at all. The unwinder seems to check for NULL personality before calling it. > I might think we'd record this in cfun->eh, not on the > decl though... That occured to me as well ... I'll see what I can do tomorrow. > > > The only thing I can think of is to record the fact that the > > > GIMPLE_TRY came from c++/java in the eh_region tree, which would > > > allow the RESX expander to emit the proper function for this > > > particular region. It's not elegant, but it should work. > > > > With your EH rewrite we could make this function explicit in the IL, > > can we? > > We can. Though I was considering recording a flag rather than > the exact decl. I do not want to encourage ABIs to muck about > with the generic EH representation. Ok, I'll leave this one alone for now, too. Richard.