This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++0x] contiguous bitfields race implementation
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 01 Sep 2011 09:16:19 -0500
- Subject: Re: [C++0x] contiguous bitfields race implementation
- References: <4DC8155A.3040401@redhat.com> <4E2E0264.30909@redhat.com> <4E2EED10.5030901@redhat.com> <4E2EF1E7.4020606@redhat.com> <4E2EFA1C.10803@redhat.com> <4E2EFB89.7060503@redhat.com> <CAFiYyc2Li+KXHKsG268UvPWJE-s+wVNuC7A5GsT8f5dTV9Gzsw@mail.gmail.com> <CAFiYyc0TnEwvrUG2oofTp1NNBfxVuKPze7W1FOni6XybbY0D8g@mail.gmail.com> <CAFiYyc1Z95E8gsyvrR=EsHXo30Qyz3dN1DmS+os1ROzwTcPC3Q@mail.gmail.com> <CAFiYyc0+mTBfXtDdNaYGExHwk3CBDK63jhehwEtMcMh+mtGbUg@mail.gmail.com> <4E3C2773.30502@redhat.com> <CAFiYyc0hYNQ+uCc_4VUTvME9FjVYWD=6fipWb7r46DjtA60vYg@mail.gmail.com> <4E417EE4.9040501@redhat.com> <CAFiYyc3Dsj_-JKby=u1rEdKewXtqP3qc6b7iyGEAhc1GFW=1LQ@mail.gmail.com> <4E495D11.5000306@redhat.com> <4E57EBDC.9090900@redhat.com> <CAFiYyc16y44Y+-ivxD-1dzL3Yxuf8fLHqkpkj7C55kkd6qGUsg@mail.gmail.com> <4E5D284A.7080006@redhat.com> <CAFiYyc2u4GvL2jvTcNmWsQ9oy-0CDcbSdC4ebUxcwR_6ML+xng@mail.gmail.com> <4E5E78D2.4050105@redhat.com> <CAFiYyc2poGB0SzcC3Qx2U+pgTHu+h2GmUiPcHzKqSYdttjPkeA@mail.gmail.com>
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?
BTW, we don't need to round up to the next byte here, do we?
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;
}
...
...
...