[llvm-commits] [126245] Fix http://lists.cs.uiuc.edu/pipermail/llvm-commits/ Week-of-Mon-20070416/047943.html
Devang Patel
dpatel at apple.com
Tue Apr 17 13:57:32 PDT 2007
Hi,
if
(StartOffsetInBits > FirstUnallocatedByte*8)
is true then
(StartOffsetFromByteBoundry == 0)
is always true. If so, we could simply this even further. In other
words, if we need pad bytes for a new field then it always starts at
byte boundary. Can you think of an example where this is not true ?
Thanks,
-
Devang
On Apr 17, 2007, at 1:42 PM, Duncan Sands wrote:
> Hi Devang, I just posted a fix which fixes some other issues too.
> A few lines earlier:
>
> if (StartOffsetFromByteBoundry != 0) {
> // New field does not start at byte boundry.
> PadBits = StartOffsetInBits - (FirstUnallocatedByte*8);
> PadBytes = PadBits/8 + 1;
> }
>
> PadBytes += StartOffsetInBits/8-FirstUnallocatedByte;
>
> If StartOffsetFromByteBoundry != 0, then PadBytes gets added to twice,
> setting it to 2*PadBits/8 + 1.
>
>> Pad = ArrayType::get(Pad, PadBytes);
>> Info.addElement(Pad, FirstUnallocatedByte, PadBytes);
>> FirstUnallocatedByte = StartOffsetInBits/8;
>> - // This field will use some of the bits from this PadBytes.
>> - FieldSizeInBits = FieldSizeInBits - (PadBytes*8 - PadBits);
>> + // This field will use some of the bits from this PadBytes, if
>> + // starting offset is not at byte boundry.
>> + if (StartOffsetFromByteBoundry != 0)
>> + FieldSizeInBits = FieldSizeInBits - (8 - PadBits);
>
> Here PadBits can be bigger than 8, which will lead to a bad result :)
> Even if it is less than 8 this can create a negative FieldSizeInBits.
> For example, if FieldSizeInBits=1, StartOffsetFromByteBoundry=1, then
> typically PadBits=1, meaning you are setting FieldSizeInBits to -6
> here!
>
>> }
>>
>> // Now, Field starts at FirstUnallocatedByte and everything is
>> aligned.
>
> Best wishes,
>
> Duncan.
More information about the llvm-commits
mailing list