This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]