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

[Richard Guenther <richard dot guenther at gmail dot com>]

On Mon, Mar 26, 2012 at 9:43 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> Isn't DECL_OFFSET_ALIGN completely useless if it is "relative"?
>
> Good question.

The only use of DECL_OFFSET_ALIGN I see is in stor-layout.c itself:

  /* If this field ended up more aligned than we thought it would be (we
     approximate this by seeing if its position changed), lay out the field
     again; perhaps we can use an integral mode for it now.  */
  if (! integer_zerop (DECL_FIELD_BIT_OFFSET (field)))
    actual_align = (tree_low_cst (DECL_FIELD_BIT_OFFSET (field), 1)
                    & - tree_low_cst (DECL_FIELD_BIT_OFFSET (field), 1));
  else if (integer_zerop (DECL_FIELD_OFFSET (field)))
    actual_align = MAX (BIGGEST_ALIGNMENT, rli->record_align);
  else if (host_integerp (DECL_FIELD_OFFSET (field), 1))
    actual_align = (BITS_PER_UNIT
                   * (tree_low_cst (DECL_FIELD_OFFSET (field), 1)
                      & - tree_low_cst (DECL_FIELD_OFFSET (field), 1)));
  else
    actual_align = DECL_OFFSET_ALIGN (field);
  /* ACTUAL_ALIGN is still the actual alignment *within the record* .
     store / extract bit field operations will check the alignment of the
     record against the mode of bit fields.  */

which again computes a "relative" actual_align.  Removing DECL_OFFSET_ALIGN
would also get rid of that odd scaling of operand 2 of COMPONENT_REFs.

>> 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".
>
> DECL_ALIGN is supposed to be the absolute counterpart. ?I think we indeed can't
> really in stor-layout, so the only place is very likely get_bit_range.

OTOH if DECL_ALIGN is absolute then if the first field of a record type has
DECL_ALIGN that is a multiple of BITS_PER_UNIT we know we can use
the present stor-layout code?  So we can check that and give up computing
representatives at all for a record type if that does not hold.

Richard.

> --
> Eric Botcazou