From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31873 invoked by alias); 8 Sep 2009 15:48:47 -0000 Received: (qmail 31704 invoked by uid 22791); 8 Sep 2009 15:48:43 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS 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; Tue, 08 Sep 2009 15:48:37 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n88FmYNO031578; Tue, 8 Sep 2009 11:48:34 -0400 Received: from stone.twiddle.home (vpn-227-91.phx2.redhat.com [10.3.227.91]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n88FmXbX004985; Tue, 8 Sep 2009 11:48:34 -0400 Message-ID: <4AA67CD1.8020602@redhat.com> Date: Tue, 08 Sep 2009 15:48:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3 MIME-Version: 1.0 To: Richard Guenther CC: gcc-patches@gcc.gnu.org, Diego Novillo Subject: Re: [PATCH] Merge from LTO: eh_personality changes References: <4AA293E4.8090301@redhat.com> <4AA2A9D7.3030406@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 2009-09/txt/msg00531.txt.bz2 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 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. I might think we'd record this in cfun->eh, not on the decl though... >> 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. r~