Re: Possible Bug

[Richard Guenther <richard.guenther@gmail.com>]

On Mon, Mar 28, 2011 at 1:36 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> On 03/28/2011 01:06 PM, Richard Guenther wrote:
>>>
>>> /* GCC uses 8-byte loads and register passing even though sizeof = 6 */
>>> typedef struct __attribute__((__packed__))
>>> {
>>>   unsigned chr            :16;
>>>   unsigned loc            :32;
>>> } GENOME_LOC_TYPE_2;
>>>
>>> //#define GENOME_LOC_TYPE GENOME_LOC_TYPE_1
>>> #define GENOME_LOC_TYPE GENOME_LOC_TYPE_2
>>>
>>> static __attribute__((__noclone__,__noinline__))
>>> int f(GENOME_LOC_TYPE x)
>>> {
>>>  return x.loc;
>>> }
>>>
>>> GENOME_LOC_TYPE h;
>>> GENOME_LOC_TYPE *g =&h;
>>>
>>> int
>>> main()
>>> {
>>>  printf ("%d %d\n", sizeof (GENOME_LOC_TYPE),
>>>                     __alignof__(GENOME_LOC_TYPE));
>>>  return f(*g);
>>> }
>>>
>>>
>>> Both definitions have a (sizeof = 6, alignof = 1) but GCC loads the
>>> second
>>> with an 8-byte load.  It's really an ugly bug if I understood it
>>> correctly,
>>> because I would have expected the second struct to have sizeof = 8.  The
>>> two
>>> final bytes are not padding, they are what's left of the unsigned int
>>> from
>>> which the bitfields are carved.  If that were the correct fix for the
>>> bug,
>>> it would be a change to the ABI.
>>
>> At expansion time we have the following for the call argument:
>>
>>  <mem_ref 0x7ffff7ff9118
>>     type<record_type 0x7ffff5b295e8 GENOME_LOC_TYPE_2 packed type_0 BLK
>>         size<integer_cst 0x7ffff5b256b8 constant 48>
>>         unit size<integer_cst 0x7ffff5b25708 constant 6>
>>         align 8 symtab 0 alias set -1 canonical type 0x7ffff5b29540
>>
>> which looks ok to me.
>
> It already isn't, why is the alignment 8 if __alignof__ (GENOME_LOC_TYPE_2)
> is 1?
>
> The other question is a layout question, should the packed attribute affect
> the removal of padding from the last bitfield element?  That's a very
> different kind of padding, and it affects whether the size of the struct
> should be 6 or 8?  Note this is slightly different from the problem in
> -Wpacked-bitfield-compat.
>
> In fact, should the poster's desired layout (the same as GENOME_LOC_TYPE_1,
> I guess) be achievable at all with bitfields, even in combination with the
> packed attribute?

Btw, this looks like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043

Richard.

> Paolo
>