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]

Re: sizetype, bitsizetype and DECL_FIELD_BITPOS


> 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)


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