On Mon, 26 Mar 2012, Eric Botcazou wrote:
> > Uh. When is a field a bit field though? At least stor-layout.c
> > resets DECL_BIT_FIELD
> > when local relative alignment is "proper" and the filed has an integer
> > mode. That's
> > overly optimistic if the record is placed at a bit position. Of
> > course we still have
> > DECL_BIT_FIELD_TYPE, but I wonder what the DECL_BIT_FIELD flag is for if
> > we cannot really know whether the field in the end is a "bitfield"
> > anyway... (what value do the various field-decls in a component-ref chain
> > have anyway if the real interpretation is subject to the containing object,
> > which might be even only
> > specified by the type used for an indirect ref ...)
>
> We're talking about a bit field with record type here, so anything calculated
> within the record type in isolation is essentially invalidated for the bit
> field in question. Fortunately this only occurs in Ada, which doesn't use
> the
> very questionable C++ memory model (fingers crossed for the future. :-)
;)
Btw, I put things in stor-layout.c exactly to allow a langhook
eventually controlling things for the bitfield representative.
Mind adding one that simply disables them completely for Ada?
Or maybe, for selected record types, so that we do
if (lang_hooks.types.lower_bitfield_layout (rli->t))
finish_bitfield_layout (rli->t);
? Letting the FE decide when to punt is certainly better than
trying to figure it out from stor-layout.c code. I suppose
for types that are supposed to interoperate with C / C++ using
the C / C++ rules makes sense (I suppose there is sth like
C/C++ interoperability with Ada).
Richard.
