On Mon, Dec 17, 2012 at 11:26:23AM +0100, Richard Biener wrote:
> On Mon, Dec 17, 2012 at 11:16 AM, Marek Polacek wrote:
> > On Mon, Dec 17, 2012 at 10:27:54AM +0100, Richard Biener wrote:
> >> This looks like the wrong place to fix (the delete-basic-block cfghook
> >> tryings to fixup loops are i
On Mon, Dec 17, 2012 at 11:26 AM, Richard Biener
wrote:
> On Mon, Dec 17, 2012 at 11:16 AM, Marek Polacek wrote:
>> On Mon, Dec 17, 2012 at 10:27:54AM +0100, Richard Biener wrote:
>>> This looks like the wrong place to fix (the delete-basic-block cfghook
>>> tryings to fixup loops are incredibly
On Mon, Dec 17, 2012 at 11:16 AM, Marek Polacek wrote:
> On Mon, Dec 17, 2012 at 10:27:54AM +0100, Richard Biener wrote:
>> This looks like the wrong place to fix (the delete-basic-block cfghook
>> tryings to fixup loops are incredibly fragile, because usually
>> delete_basic_block
>> is called be
On Mon, Dec 17, 2012 at 10:27:54AM +0100, Richard Biener wrote:
> This looks like the wrong place to fix (the delete-basic-block cfghook
> tryings to fixup loops are incredibly fragile, because usually
> delete_basic_block
> is called because of another cfg manipulation takes place). That is,
> th
On Mon, Dec 17, 2012 at 1:21 AM, Marek Polacek wrote:
> Here's a fix for the C++ TC part of this PR. The issue was
> that we had a loop with header and two latches, and via delete_basic_block
> we deleted both latches, but we weren't removing the loop properly.
> This ICEd later on because in mer
Here's a fix for the C++ TC part of this PR. The issue was
that we had a loop with header and two latches, and via delete_basic_block
we deleted both latches, but we weren't removing the loop properly.
This ICEd later on because in merge_latch_edges there's an assert:
gcc_assert (latches.length (
