Paul Schlie <schlie@comcast.net> writes:
>> or when HOST_BITS_PER_WIDE_INT != 32 ;) (Because build_int_cst_wide
>> expects HOST_WIDE_INTs.)
>> ...
>> tree_val = build_int_cst_wide (get_gcov_type (),
>> - val & 0xffffffffull, val >> 32);
>> + (unsigned HOST_WIDE_INT) val,
>> + val >> (HOST_BITS_PER_WIDE_INT - 1) >> 1);
>
> Sorry, I'm a bit confused; when building an expression for evaluation on a
> target, shouldn't all the operations be based solely on the attributes of
> that target's variable type, not the host's? (i.e. what does an arbitrary
> host's HOST_WIDE_INT precision have to do with a target expression operand
> precision?)
Sorry, I don't understand your objection. Have you looked at how
integers are represented at the tree level? They're represented
as pairs of HOST_WIDE_INTs: a low integer and a high integer.
build_int_cst_wide() returns an INTEGER_CST for such a pair.
Ah, I see the comments in tree.def are a bit out of date:
/* Contents are in TREE_INT_CST_LOW and TREE_INT_CST_HIGH fields,
32 bits each, giving us a 64 bit constant capability. INTEGER_CST
nodes can be shared, and therefore should be considered read only.
They should be copied, before setting a flag such as
TREE_OVERFLOW. If an INTEGER_CST has TREE_OVERFLOW or
TREE_CONSTANT_OVERFLOW already set, it is known to be unique.
INTEGER_CST nodes are created for the integral types, for pointer
types and for vector and float types in some circumstances. */
DEFTREECODE (INTEGER_CST, "integer_cst", tcc_constant, 0)
"32 bits" should be "HOST_BITS_PER_WIDE_INT bits" and "64 bits"
should be "HOST_BITS_PER_WIDE_INT * 2 bits". Is that what's
confusing you?
Richard