From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 560 invoked by alias); 10 Sep 2009 16:23:07 -0000 Received: (qmail 537 invoked by uid 22791); 10 Sep 2009 16:23:06 -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 16:22:59 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8AGMvDY016090; Thu, 10 Sep 2009 12:22:57 -0400 Received: from stone.twiddle.home (vpn-227-149.phx2.redhat.com [10.3.227.149]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n8AGMuhK029017; Thu, 10 Sep 2009 12:22:57 -0400 Message-ID: <4AA927E0.3080104@redhat.com> Date: Thu, 10 Sep 2009 16:23: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> <4AA92044.3050800@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/msg00711.txt.bz2 On 09/10/2009 09:05 AM, Richard Guenther wrote: > No. It needs it for OMP and the MUST_NOT_THROW regions that generates. Ah, but we just need *some* personality, not any particular personality, since we don't have a language spec telling us that we have to call a particular abort function. Same goes for C. So you have C and Fortran leave its lang.eh_personality NULL, which leaves DECL_EH_PERSONALITY NULL, which allows your inliner change to drop in the C++ (or Ada, etc) personality when needed. If we arrive at assembly output time in get_personality_function and find that the function has a non-NULL fun->eh->region_tree, then we supply the default __gcc_personality_v0. (Note the non-null region_tree here, since we need *some* personality even to handle cleanup regions at runtime. But *any* personality can handle cleanup regions, which is why we don't want to select a DECL_EH_PERSONALITY too early for that case.) r~