On Mon, Mar 26, 2012 at 9:18 AM, Eric Botcazou <ebotca...@adacore.com> wrote:
>> Btw, now checking with gdb, DECL_OFFSET_ALIGN is always 128 for
>> all of the fields - that looks bogus.  DECL_ALIGN is 1, but that
>> doesn't mean DECL_OFFSET_ALIGN should not be 1 as well, no?
> DECL_OFFSET_ALIGN is set to BIGGEST_ALIGNMENT for the first field, see
> start_record_layout.  If DECL_FIELD_OFFSET doesn't change for the next fields,
> DECL_OFFSET_ALIGN will very likely not either.

Isn't DECL_OFFSET_ALIGN completely useless if it is "relative"?

I placed the code in stor-layout.c and computed the field
representatives per record type
(and not per full object) because that's the only way to do it
scalable and that does not
require excessive space.  The invariant should be that you can replace
the bitfield
access with an access of the representative plus a bitfield extract
from the read value.
If bit-aligned representatives need an integral mode then the access
is not constrained
by the representatives size which means having a representative in
this case is useless
(for correctness), so you can as well set none for these cases.  But I
wonder how we can
even detect non-byte-alignment?  I see the field has DECL_ALIGN of 1,
but isn't that
"relative" as well?  At least I'm totally confused with
DECL_OFFSET_ALIGN being "relative".


> --
> Eric Botcazou

Reply via email to