From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15876 invoked by alias); 8 Sep 2009 12:37:24 -0000 Received: (qmail 15842 invoked by uid 22791); 8 Sep 2009 12:37:24 -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 12:37:17 +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 AFA236CB00; Tue, 8 Sep 2009 14:37:14 +0200 (CEST) Date: Tue, 08 Sep 2009 12:37: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: <4AA2A9D7.3030406@redhat.com> Message-ID: References: <4AA293E4.8090301@redhat.com> <4AA2A9D7.3030406@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/msg00514.txt.bz2 On Sat, 5 Sep 2009, Richard Henderson wrote: > On 09/05/2009 10:24 AM, Richard Guenther wrote: > > > Also, I think you need to add something to prevent inlining of functions > > > that use different personality functions. > > > > I don't think so. The IL should be still in a state where the inlined > > pieces would simply inherit the callers personality. But maybe I'm > > missing something? > > You're missing that the personality functions have to deal with > the language's runtime types, as recorded in the catch type_list > and the allowed-exceptions type_list. > > You can't expect the Ada personality to deal with C++ runtime types. 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. > > > Do you have a strategy for handling > > > > > > if (targetm.arm_eabi_unwinder) > > > unwind_resume_libfunc = init_one_libfunc ("__cxa_end_cleanup"); > > > > > > since this function is only used for c++/java? > > > > No. Do you have something in mind? > > 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? > > I see the patch is somewhat incomplete (there's also > > lang_eh_runtime_type, but maybe we never call add_type_for_runtime > > after a frontend finishes - in which case this should have been > > a langhook?) - and in general the integration of EH aware and > > non-EH aware code with LTO still needs work and thought. > > We do all the calls to add_type_for_runtime during > pass_lower_eh, right toward the beginning of compilation. > I'm pretty sure we don't need to do anything else with > that lang hook for LTO. Ok. I'll modify the patch to make this a true langhook and maybe move the eh-personality also to a langhook called from eh lowering. How does that sound? Thanks, Richard.