[PATCH] New ia64 @slotcount pseudo func (4th try)

[Douglas B Rupp]

I ran objdump -d on a version of the object file (unwind-ia64.o) from 
before we started down slotcounts in the assembler, calculated the 
slotcount by hand and it came out right in this case with a frag_off of 
zero, even though the labels are clearly in different frags, so now I'm 
really confused. Giving up until someone tells me something.

Douglas B Rupp wrote:
> Seems like from this comment rs_align_code could be handled in 
> frag_offset_fixed_p, no?
> 
>   /* Align code.  The fr_offset field holds the power of 2 to which
>      to align.  This type is only generated by machine specific
>      code, which is normally responsible for handling the fill
>      pattern.  The fr_subtype field holds the maximum number of
>      bytes to skip when aligning, or 0 if there is no maximum.  */
>   rs_align_code,
> 
> 
> Douglas B Rupp wrote:
>> Some problems have appeared. I should have run more complex tests.
>>
>> frag_offset_fixed_p is returning false for some cases involving the 
>> begin epilogue label slotcount from the begin function label
>>
>>         data4.ua        @slotcount(.LEB56-.LFB56)
>>
>> -------------------
>> (gdb) print frag1
>> $21 = (const fragS *) 0x766890
>> (gdb) print frag2
>> $22 = (const fragS *) 0x7667c8
>> (gdb) n
>> 407       frag = frag1;
>> (gdb) n
>> 408       while (frag->fr_type == rs_fill)
>> (gdb) print frag->fr_type
>> $23 = rs_align_code
>> (gdb) n
>> 422       off = frag1->fr_address - frag2->fr_address;
>> (gdb) print frag->fr_type
>> $24 = rs_align_code
>> (gdb) print off
>> $25 = 0
>> (gdb) n
>> 423       frag = frag2;
>> (gdb)
>> 424       while (frag->fr_type == rs_fill)
>> (gdb) print frag->fr_type
>> $26 = rs_align_code
>> (gdb) n
>> 437       return FALSE;
>>
>