From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 632 invoked by alias); 10 Sep 2009 16:02:15 -0000 Received: (qmail 32716 invoked by uid 22791); 10 Sep 2009 16:02:12 -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; Thu, 10 Sep 2009 16:02:06 +0000 Received: from relay2.suse.de (relay-ext.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 EDC85457F0; Thu, 10 Sep 2009 18:02:03 +0200 (CEST) Date: Thu, 10 Sep 2009 16:02: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: <4AA92044.3050800@redhat.com> Message-ID: References: <4AA293E4.8090301@redhat.com> <4AA2A9D7.3030406@redhat.com> <4AA67D0C.8000704@redhat.com> <4AA92044.3050800@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/msg00706.txt.bz2 On Thu, 10 Sep 2009, Richard Henderson wrote: > 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; Yep - it's the patch that doesn't work, just to explain things. > > * 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. I can do that. > > + 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. Fixed. > > *** 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? Good question - I'll check. > > + 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? It doesn't seem to work - I get ICEs in #2 0x00000000006d897b in output_addr_const (file=0x163c040, x=0x2aaaacaa5c80) at /space/rguenther/src/svn/trunk/gcc/final.c:3619 3619 output_operand_lossage ("invalid expression as operand"); (gdb) call debug_rtx (x) (mem:QI (symbol_ref:DI ("__gcc_personality_v0") [flags 0x41]) [0 S1 A8]) #3 0x000000000064d3fd in dwarf2out_do_cfi_startproc (second=0 '\000') at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:3851 3851 output_addr_const (asm_out_file, ref); Thanks, Richard.