From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8661 invoked by alias); 10 Nov 2011 13:29:32 -0000 Received: (qmail 8651 invoked by uid 22791); 10 Nov 2011 13:29:31 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,TW_CF X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 10 Nov 2011 13:29:16 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1ROUgr-0005L5-Ow from Bernd_Schmidt@mentor.com ; Thu, 10 Nov 2011 05:29:13 -0800 Received: from [127.0.0.1] ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Nov 2011 13:29:11 +0000 Message-ID: <4EBBD1A0.3060101@codesourcery.com> Date: Thu, 10 Nov 2011 14:13:00 -0000 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110920 Lightning/1.0b3pre Thunderbird/3.1.12 MIME-Version: 1.0 To: Richard Guenther CC: Hans-Peter Nilsson , hp@axis.com, amodra@gmail.com, gcc-patches@gcc.gnu.org Subject: Re: Revert "PowerPC shrink-wrap support 3 of 3" References: <201111101143.pAABh70b007686@ignucius.se.axis.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------010606060800070108040605" 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: 2011-11/txt/msg01413.txt.bz2 This is a multi-part message in MIME format. --------------010606060800070108040605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-length: 1032 On 11/10/11 13:14, Richard Guenther wrote: > Fair enough. You can count me as "one" then, and I'll defer to Bernd > to either provide a fix or ack the revert. I'm trying to track it down. In 189r.outof_cfglayout, we have (insn 31 33 35 3 (use (reg/i:SI 0 r0)) ../../../../baseline-trunk/libstdc++-v3/libsupc++/new_opv.cc:34 -1 (nil)) ;; Successors: EXIT [100.0%] (fallthru) ;; lr out 0 [r0] 11 [fp] 13 [sp] 14 [lr] 25 [sfp] 26 [afp] ;; live out 0 [r0] 11 [fp] 13 [sp] 25 [sfp] 26 [afp] followed by a number of other basic blocks, so that looks wrong to me. outof_cfglayout seems to assume that fallthrough edges to the exit block are OK and don't need fixing up, and changing that seems nontrivial at first glance. The situation is first created during cfgcleanup in into_cfglayout. The following patch makes the testcase compile by stopping the compiler from moving the exit fallthru block around, but I've not checked whether it has a negative effect on code quality. HP, can you run full tests? Bernd --------------010606060800070108040605 Content-Type: text/plain; name="cfgl-exit.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cfgl-exit.diff" Content-length: 856 Index: ../baseline-trunk/gcc/cfgrtl.c =================================================================== --- ../baseline-trunk/gcc/cfgrtl.c (revision 181252) +++ ../baseline-trunk/gcc/cfgrtl.c (working copy) @@ -2735,6 +2735,16 @@ cfg_layout_can_merge_blocks_p (basic_blo if (BB_PARTITION (a) != BB_PARTITION (b)) return false; + /* If we would end up moving B's instructions, make sure it doesn't fall + through into the exit block, since we cannot recover from a fallthrough + edge into the exit block occurring in the middle of a function. */ + if (NEXT_INSN (BB_END (a)) != BB_HEAD (b)) + { + edge e = find_fallthru_edge (b->succs); + if (e && e->dest == EXIT_BLOCK_PTR) + return false; + } + /* There must be exactly one edge in between the blocks. */ return (single_succ_p (a) && single_succ (a) == b --------------010606060800070108040605--