[llvm-commits] [llvm-gcc-4.2] r51866 - /llvm-gcc-4.2/trunk/gcc/llvm-types.cpp

Dale Johannesen dalej at apple.com
Tue Jun 3 14:28:56 PDT 2008


On Jun 3, 2008, at 1:51 PM, Duncan Sands wrote:

> Hi Dale,
>
>> This patch breaks FrontendC/2008-01-28-UnionSize.c and FrontendC/
>> 2007-09-28-PackedUnionMember.c on Darwin x86-32.
>
> sorry about that, I don't understand why I didn't see it when testing
> because I sure see it now (x86-64)!  The problem is that gcc says that
> this type
>
>  union {
>    struct opaque1 *f3;
>    struct opaque2 *f4;
>    struct {
>      struct opaque3 *f5;
>      unsigned short  f6;
>    } f7;
>  };
>
> is 16 byte aligned but has a size of 10 bytes.  I thought gcc sizes
> were always a multiple of the alignment?  Anyway, ConvertUNION chooses
> to represent this using "struct opaque1 *" (the reason being that f7
> is packed, dunno why, so has alignment 1, which is less than the  
> alignment
> of the pointers).  It then observes that the size (8 bytes) is less  
> than
> the gcc size (10 bytes) so tries to pad by adding 2 bytes, resulting  
> in
>  { opaque *, [2 x i8] }
> This actually has an ABI size of 16 bytes - it is 10 bytes wide but is
> 8 bytes aligned -> 16 bytes.  This is not the same as the gcc type  
> size.
>
> I'm rather taken aback that gcc is producing type sizes that are not a
> multiple of the alignment.  I also don't understand why the alignment
> is 16.
>
> I guess most of these oddities are related to the "#pragma  
> pack(push, 2)"
> on the first line of 2007-09-28-PackedUnionMember.c.  What does that  
> mean?
> And if things are packed, shouldn't the union be converted to a  
> packed type
> or something?


The pragma means all struct/unions encountered thereafter (until the  
next such pragma) have alignment 2 and max alignment of any field is  
2.  So
struct { char c; int x; };
is size 6, alignment 2.
So the size and alignment for that union are 10 and 2, and if you  
compile it with gcc that's what they are.  I'm not sure how that's  
represented inside gcc, probably there's another field somewhere you  
need to look at.





More information about the llvm-commits mailing list