On Wed, Feb 08, 2012 at 11:55:52AM +0100, Richard Guenther wrote:
> > I'll bootstrap/regtest now just that single hunk, is that ok for
> > trunk/4.6/4.5?
>
> Yes.
Thanks, this is what I've committed after bootstrap/regtest on x86_64-linux
and i686-linux:
2012-02-08 Jakub Jelinek
PR r
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 loo
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 NE
On Tue, 7 Feb 2012, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase we hit two bugs during cfglayout merge_blocks.
>
> One is that b->il.rtl->header has some jumptable in it, followed by
> barrier. We call emit_insn_after_noloc to insert the whole b's header
> after BB_END (a) and then
Hi!
On the following testcase we hit two bugs during cfglayout merge_blocks.
One is that b->il.rtl->header has some jumptable in it, followed by
barrier. We call emit_insn_after_noloc to insert the whole b's header
after BB_END (a) and then delete_insn_chain it, with the intention that only
non-
