> From: Richard Guenther <richard.guent...@gmail.com> > Date: Thu, 10 Nov 2011 12:22:56 +0100
> On Thu, Nov 10, 2011 at 11:38 AM, Hans-Peter Nilsson > <hans-peter.nils...@axis.com> wrote: > >> From: Hans-Peter Nilsson <h...@axis.com> > >> Date: Wed, 9 Nov 2011 09:55:59 +0100 > > > >> > From: Alan Modra <amo...@gmail.com> > >> > Date: Tue, 1 Nov 2011 16:33:40 +0100 > >> > >> > On Tue, Nov 01, 2011 at 12:57:22AM +1030, Alan Modra wrote: > >> > >> > * function.c (bb_active_p): Delete. > >> > (dup_block_and_redirect, active_insn_between): New functions. > >> > (convert_jumps_to_returns, emit_return_for_exit): New functions, > >> > split out from.. > >> > (thread_prologue_and_epilogue_insns): ..here. Delete > >> > shadowing variables. Don't do prologue register clobber tests > >> > when shrink wrapping already failed. Delete all last_bb_active > >> > code. Instead compute tail block candidates for duplicating > >> > exit path. Remove these from antic set. Duplicate tails when > >> > reached from both blocks needing a prologue/epilogue and > >> > blocks not needing such. > >> > * ifcvt.c (dead_or_predicable): Test both flag_shrink_wrap and > >> > HAVE_simple_return. > >> > * bb-reorder.c (get_uncond_jump_length): Make global. > >> > * bb-reorder.h (get_uncond_jump_length): Declare. > >> > * cfgrtl.c (rtl_create_basic_block): Comment typo fix. > >> > (rtl_split_edge): Likewise. Warning fix. > >> > (rtl_duplicate_bb): New function. > >> > (rtl_cfg_hooks): Enable can_duplicate_block_p and > >> > duplicate_block. > >> > >> This (a revision in the range 181187:181189) broke build for > >> cris-elf like so: > >> See PR51051. > > > > Given that this also broke arm-linux-gnueabi, a primary > > platform, and Alan being absent until the 15th according to a > > message on IRC, I move to revert r181188. > > Is there a PR for the arm issue? It's covered by the same PR, see comment #1. I've now updated the target field. > > I think I need someone with appropriate write privileges to > > agree with that, and to also give 48h for someone to fix the > > problem. Sorry for not forthcoming on the second point. > > Did you or somebody else try to look into the problem? To decide > whether it's the "best course of action" it would be nice to know if > it's a simple error in the patch that is easy to fix. Nope, not really. Wouldn't FWIW, de jure matter, me not having write privileges to the affected area. Though, I had a quick look at the patch and nothing stood out except its intrusiveness, and it seems the patch wasn't tested on a !simple_return target (just "powerpc-linux" according to the replied-to message). brgds, H-P
