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". Richard. > -- > Eric Botcazou
