This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix cfg_layout_merge_blocks (PR rtl-optimization/52139)

On Wed, 8 Feb 2012, Jakub Jelinek wrote:

> On Wed, Feb 08, 2012 at 10:27:42AM +0100, Richard Guenther wrote:
> > Isn't it cheaper to do that before we scan all the sequences?  Thus,
> > I'd expect BLOCK_FOR_INSN to be NULL if the insn is in a sequence?
> > Like simply
> Actually, on a third look, the emit-rtl.c changes aren't needed,
> apparently NEXT_INSN even in cfglayout mode is NULL for the in bb
> insns only if it is equal to get_last_insn (), unless in the header/footer
> sequences, but for those one shouldn't call remove_insn.
> To fix this bug the
> +      /* The above might add a BARRIER as BB_END, but as barriers
> +        aren't valid parts of a bb, remove_insn doesn't update
> +        BB_END if it is a barrier.  So adjust BB_END here.  */
> +      while (BB_END (a) != first && BARRIER_P (BB_END (a)))
> +       BB_END (a) = PREV_INSN (BB_END (a));
> hunk is all that is needed (and the remaining cfgrtl.c hunks
> just a nice to have cleanup, could be postponed for 4.8).
> Without this BB_END (a) is a barrier, but deleted one, so get_last_insn ()
> was actually moved to some insn before it and therefore when we
> emit_insn_after_noloc the b bb unchained sequence, it doesn't match
> get_last_insn () when it should.
> I'll bootstrap/regtest now just that single hunk, is that ok for
> trunk/4.6/4.5?



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]