On Thu, Sep 1, 2011 at 4:16 PM, Aldy Hernandez <al...@redhat.com> wrote:
>
>> My point is, the middle-end infrastructure makes it possible for this
>> case to appear, and it seems to be easy to handle conservatively.
>> There isn't a need to wait for users to run into an ICE or an assert we
>> put
>> there IMHO. If I'd be fluent in Ada I'd write you a testcase, but I
>> ain't.
>
> Ughh, this is getting messier.
>
> Ok, I propose keeping track of the field prior (lastfld), calling
> get_inner_reference() and adding DECL_SIZE (or tbitsize if you prefer) to
> calculate maxbits without the padding.
>
> Notice the comment at the top. We can get rid of yet another call to
> get_inner_reference later.
>
> Is this what you had in mind?
That could work also for the tail-padding re-use case, yes. Note that
DECL_SIZE of the field is just the last fieds bit-precision, so ..
> BTW, we don't need to round up to the next byte here, do we?
.. rounding up to the next byte cannot hurt (dependent on what the
caller will do with that value).
Note that with all this mess I'll re-iterate some of my initial thoughts.
1) why not do this C++ (or C) specific stuff in the frontends, maybe
at gimplifying/genericization time? That way you wouldn't need to
worry about middle-end features but you could rely solely on what
C/C++ permit. It is, after all, C++ _frontend_ semantics that we
enforce here, in the middle-end, which looks out-of-place.
2) all this information we try to re-construct here is sort-of readily
available when we layout the record (thus, from layout_type and
friends). We should really, really try to preserve it there, rather
than jumping through hoops here (ideally we'd have an
(unused?) FIELD_DECL that covers the whole "bitfield group"
followed by the individual FIELD_DECLS for the bits (yep, they'd
overlap that group FIELD_DECL), and they would refer back to
that group FIELD_DECL)
Is the C++ memory model stuff going to be "ready" for 4.7?
Thanks,
Richard.
> Thanks.
> Aldy
>
> /* If we found the end of the bit field sequence, include the
> padding up to the next field... */
> if (fld)
> {
> tree end_offset, t;
> HOST_WIDE_INT end_bitpos;
>
> /* FIXME: Only call get_inner_reference once (at the beginning
> of the bit region), and use
> DECL_FIELD_OFFSET+DECL_FIELD_BIT_OFFSET throughout to
> calculate any subsequent bit offset. */
>
> /* Even if the bitfield we access (and thus the whole region) is
> at a constant offset, the field _following_ the bitregion can
> be at variable offset. In this case, do not include any
> padding. This is mostly for Ada. */
> if (TREE_CODE (DECL_FIELD_OFFSET (fld)) != INTEGER_CST)
> {
> get_inner_reference (build3 (COMPONENT_REF,
> TREE_TYPE (exp),
> TREE_OPERAND (exp, 0),
> lastfld, NULL_TREE),
> &tbitsize, &end_bitpos, &end_offset,
> &tmode, &tunsignedp, &tvolatilep, true);
>
> /* Calculate the size of the bit region up the last
> bitfield, excluding any subsequent padding.
>
> t = (end_byte_off - start_byte_offset) * 8 + end_bit_off */
> end_offset = end_offset ? end_offset : size_zero_node;
> t = fold_build2 (PLUS_EXPR, size_type_node,
> fold_build2 (MULT_EXPR, size_type_node,
> fold_build2 (MINUS_EXPR,
> size_type_node,
> end_offset,
> *byte_offset),
> build_int_cst (size_type_node,
> BITS_PER_UNIT)),
> build_int_cst (size_type_node,
> end_bitpos));
> /* Add the bitsize of the last field. */
> t = fold_build2 (PLUS_EXPR, size_type_node,
> t, DECL_SIZE (lastfld));
>
> *maxbits = tree_low_cst (t, 1);
> return;
> }
> ...
> ...
> ...
>
