This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: M32C: Do not enable PCC_BITFIELD_TYPE_MATTERS
On Tue, 10 Feb 2009, Nick Clifton wrote:
> > > Since the M32C only uses 8-bit alignment for all
> > > types, the type of a bitfield is not actually significant and it is
> >
> > Hm, that's a slightly different thing than PCC_BITFIELD_TYPE_MATTERS.
>
> Are you sure ? According to gcc/doc/tm.texi, the meaning of this define is:
>
> "The behavior is that the type written for a named bit-field
> (int, short, or other integer type) imposes an alignment for the
> entire structure, as if the structure really did contain an
> ordinary field of that type. In addition, the bit-field is
> placed within the structure so that it would fit within such a
> field, not crossing a boundary for it.
>
> Since, for the M32C, the alignment of int's short's and other types are all
> the same, and all 1 byte, the type of a bit-field does not impose any
> alignment constraint on the structure containing it, and the fields can be
> placed on any byte boundary.
Yes, I'm sure. The last quoted sentence is key.
PCC_BITFIELD_TYPE_MATTERS would cause the "X : 0" fields to pad
to the boundary of a X.
Maybe M32C has something defined that causes that to *not*
happen despite PCC_BITFIELD_TYPE_MATTERS being defined? It
doesn't for CRIS last time I checked; at the time the warnings
of concern being added.
> > > struct foo1 { char x; char :0; char y; };
> > > struct foo2 { char x; int :0; char y; };
> > > int s[sizeof (struct foo1) != sizeof (struct foo2) ? 1 : -1];
> > >
> > > Assumes that the alignment of the "int" type is greater than the
> > > alignment of the "char" type.
> >
> > No, it does not.
>
> I think that it does. The "char :0" and "int :0" fields do not contribute any
> space to the structure, but they do impose alignment and packing constraints
> on the structure because of their types.
That's supposed to be controlled by PCC_BITFIELD_TYPE_MATTERS.
The code is taken from the documentation!
> These constraints are only
> detectable by the sizeof() operators on the last line of the test if they are
> different, and for the M32C they are not.
Which means you in effect had a non-PCC_BITFIELD_TYPE_MATTERS
target despite having it defined! That's sounds like a bug.
> > The test above might be wrong for your target
> > for some reason, but your analysis sounds mixed up with that of
> > default_packed.
>
> Umm - what is default_packed ? It sounds like it means that structures
> default to having the "packed" attribute applied to them, but I could not find
> any reference to this in the gcc sources.
I tried to convey a target ABI with the default layout
(structures and other objects) without padding nor requiring nor
assuming other alignment, in terms of target-supports.exp
specifiers; see check_effective_target_default_packed. Like
CRIS. Like M32C, I guess.
brgds, H-P