This is the mail archive of the gcc@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] |
Daniel Berlin wrote:
IOW, you are lying to the middle-end about the size of the fields. Why is the type not a 6 bit integer?
layout_decl (tree decl, unsigned int known_align)
...
/* Usually the size and mode come from the data type without change,
however, the front-end may set the explicit width of the field, so its
size may not be the same as the size of its type. This happens with
bitfields, of course (an `int' bitfield may be only 2 bits, say), but it
also happens with other fields.
The C front-end behaves similarily, creating
<field_decl 0xb7429398 x type <integer_type 0xb7429450>
external packed bit-field nonaddressable decl_4 QI file tt.c line 3
size <integer_cst 0xb742fd98 constant invariant 3>
unit size <integer_cst 0xb73aa228 1>
<integer_type 0xb7429450 sizes-gimplified public QI size <integer_cst constant invariant 8> unit size <integer_cst constant invariant 1> align 8 symtab 0 alias set -1 precision 3 min <integer_cst -4> max <integer_cst 3>>
You'll note we actually created a new type for this :) but anyway,
Thinking harder about it, you might be better off then making everything based on TYPE_SIZE then, since we don't always have the FIELD_DECL's handy.This is the correct fix, however, if you are going to lie to the middle end about TYPE_SIZE so that the TYPE_SIZE and DECL_SIZE do not match.
Well, I'm actually not sure we have a choice. And I'm not sure it is
really a lie. A restricted set of values happen to fit in a lower number
of bits than what some type allows, it is not obvious that it makes those
values of a different type.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |