This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Possible Bug


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
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]