Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere

[Richard Guenther <rguenther at suse dot de>]

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.