This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Possible Bug
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.