This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: sizetype, bitsizetype and DECL_FIELD_BITPOS
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Subject: Re: sizetype, bitsizetype and DECL_FIELD_BITPOS
- From: Joern Rennecke <amylaar at cygnus dot co dot uk>
- Date: Thu, 30 Dec 1999 01:06:18 +0000 (GMT)
- CC: gcc at gcc dot gnu dot org
> Also, there is a comment referencing DECL_SIZE_UNIT, but I see no such
> macros. Then there's the code in get_inner_reference: first of all,
> is OFFSET of bitsizetype or sizetype?
OFFSET is sizetype.
> I see places where it is
> used in both contexts and, unless I'm missing something, we are missing
> conversions.
I suppose you mean this?
offset = size_binop (PLUS_EXPR, offset,
size_binop (EXACT_DIV_EXPR, var,
size_int (BITS_PER_UNIT)));
size_binop is documented to get its type from sizetype.
I appears to do something different, which will matter if offset is zero
and has a type that is not sizetype.
Otherwise, the EXACT_DIV_EXPR should be translated to a straight shift and
the rest of the computation should be done in sizetype.
> Secondly, the array code talks about if the bitsize
> computation overflow, but I see no overflow test.
Yes, indeed, the comment is imprecise at best. A non-zero
TREE_INT_CST_HIGH (xindex) doesn't mean that an overflow occured, it
just means that pbitpos is unsuitable to pass the result back to the
caller. That can happen in a 32->64 bit cross-compilation, for instance.
Incidentally, pbitpos is an int *, but it would have to be a HOST_WIDE_INT
to accomodate TREE_INT_CST_LOW (xindex)