Basic block numbers no longer in sequence

[Richard Earnshaw]

>   In message < 199910041809.TAA10358@sun52.NIS.cambridge >you write:
>   > I considered this, and I don't think you are right.  The important point 
>   > is that we are really removing A, not B as merge_blocks_nomove thinks.  If 
>   > A appears after B then it is still correct to compact from where A used to 
>   > be.  What the patch does is to make B appear as though it is A, so that 
>   > compaction starts from the correct place.
> I *think* I see how your two cases work, but I'm not 100% convinced.  I'll
> trust you :-)
> 
> However, I still think we botch the case where A comes after B and we are
> moving B (ie, the move_successor case).
> 
> 
> A After B
> 
> Before
> 	...
> 	4
> 	5	B
> 	6
> 	...
> 	9
> 	10	A
> 	11
> 
> We physically move B after A, which gives us:
> 
> 	...
> 	4
> 	6
> 	...
> 	9
> 	10	A
> 	5	B
> 	11
> 
> Then we merge A & B and renumber from A.  Which gives
> 
> 	...
> 	4
> 	6
> 	...
> 	9
> 	10	A + B
> 	11
> 
> Note how we've left a hole.    Unless I'm missing something.
> 
It works because expunge_block goes:
	for (i = b->index ...

so it starts with the index of B, which still contains 5 in your example.

> 
> I guess building tests for the 4 cases would probably make this a lot easier
> to wrap our heads around since we can actually poke at it with the debugger :-)
> 

I'll see if I can concoct some test cases when I have a few spare moments 
(ah! spare time ... an interesting concept... :-)

R.