Re: Possible Bug

[Michael Matz <matz@suse.de>]

Hi,

On Mon, 28 Mar 2011, Paolo Bonzini wrote:

> > 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 aligns are printed in bits.  It really is okay, as is the MEM.

> The other question is a layout question, should the packed attribute 
> affect the removal of padding from the last bitfield element?

A hypothetical question because we can't change this behaviour after about 
15 years.  Even if we could I'd argue that the current behaviour is 
correct (because we lack another attribute that would say 'and please also 
pack arrays of this type tightly', which then would finally imply that 
final padding is also removed, and hence we'd then hit this very same bug 
with testcases using _that_ attribute instead of packed).

As some digging shows, already GCC 1.35 had effectively the same code.  
As soon as parameters are passed in registers GCC loads the parts fitting 
into registers as full words.  We could simply sorry() for these cases, as 
they never worked correctly.  Though I suppose that's quite unforgiving, 
as most of the time (struct in question not passing page border) it works 
fine.


Ciao,
Michael.