From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12597 invoked by alias); 10 Sep 2009 15:50:39 -0000 Received: (qmail 12574 invoked by uid 22791); 10 Sep 2009 15:50:37 -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; Thu, 10 Sep 2009 15:50:32 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8AFoU62028564; Thu, 10 Sep 2009 11:50:30 -0400 Received: from stone.twiddle.home (vpn-227-149.phx2.redhat.com [10.3.227.149]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n8AFoUXC012701; Thu, 10 Sep 2009 11:50:30 -0400 Message-ID: <4AA92044.3050800@redhat.com> Date: Thu, 10 Sep 2009 15:50: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> <4AA67D0C.8000704@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/msg00702.txt.bz2 On 09/10/2009 07:52 AM, Richard Guenther wrote: >> Doesn't seem to work. Instead I tried to fall back to >> the gcc personality for detecting empty type lists, again setting >> a cfi personality for all functions we emit. But that doesn't work >> either (it seems catch (...) doesn't work with the gcc personality, >> g++.dg/eh/loop1.C fails). Interesting. I wouldn't have expected that. Though your patch doesn't seem to indicate that: > + case ERT_CATCH: > + /* An empty type list is ok with the default C EH personality. */ > + if (i->u.eh_catch.type_list) > + return true; > + break; > * langhooks-def.h (LANG_HOOKS_INIT_EH): Define. > (LANG_HOOKS_EH_RUNTIME_TYPE): Likewise. > (LANG_HOOKS_INITIALIZER): Adjust. > (lhd_pass_through_t): Declare. > * langhooks.h (struct lang_hooks): Add init_eh and eh_runtime_type. > * langhooks.c (lhd_pass_through_t): New function. ... > * toplev.c (eh_personality_decl): New. I'm surprised you're not taking the opportunity to make the eh_personality_thingy a proper lang hook. > + case ERT_MUST_NOT_THROW: > + case ERT_CLEANUP: > + /* Ok with the default C EH personality. */ > + break; MUST_NOT_THROW is not ok with default personality. You'll wind up invoking abort instead of std::terminate. > *** gcc/fortran/f95-lang.c.orig 2009-09-10 13:40:45.000000000 +0200 > --- gcc/fortran/f95-lang.c 2009-09-10 14:18:42.000000000 +0200 > *************** gfc_maybe_initialize_eh (void) > *** 1155,1164 **** > return; > > gfc_eh_initialized_p = true; > ! eh_personality_libfunc > ! = init_one_libfunc (USING_SJLJ_EXCEPTIONS > ! ? "__gcc_personality_sj0" > ! : "__gcc_personality_v0"); > default_init_unwind_resume_libfunc (); > using_eh_for_cleanups (); > } > --- 1155,1164 ---- > return; > > gfc_eh_initialized_p = true; > ! eh_personality_decl > ! = build_personality_function (USING_SJLJ_EXCEPTIONS > ! ? "__gcc_personality_sj0" > ! : "__gcc_personality_v0"); Surely Fortran can simply avoid setting this up at all? > + rtx > + get_personality_function (tree decl) > + { > + tree personality = DECL_FUNCTION_PERSONALITY (decl); > + tree name; > + > + if (!personality&& !eh_personality_decl) > + return NULL; > + > + if (!personality) > + return init_one_libfunc (USING_SJLJ_EXCEPTIONS > + ? "__gcc_personality_sj0" > + : "__gcc_personality_v0"); > + > + name = DECL_ASSEMBLER_NAME (personality); > + > + return init_one_libfunc (IDENTIFIER_POINTER (name)); > + } Why in the world are you extracting the name and invoking init_one_libfunc instead of using the DECL_RTL of the function_decl? And what's with the eh_personality_decl check at this point? r~