Re: RFA: Fix value-prof.c call to build_int_cst_wide

[Richard Sandiford <rsandifo at redhat dot com>]

Paul Schlie <schlie@comcast.net> writes:
>> 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?
>
> Yes, it wasn't an objection, just a statement of confusion about the
> presumption of HOST_WIDE_INT's size, and it's relationship to the
> target's gcov_type data size? (as summarized by the "should be" in
> "32 bits" should be "HOST_BITS_PER_WIDE_INT bits", as it wasn't clear
> that it would necessarily always be the case? or simply doesn't matter,
> as even if 64 bits wide, it would still allow a 32-bit gcov_type to be
> safely represented within a pair of 64-bit values?)

"should be" as in "should read".  In other words, the documentation is
wrong: you can't assume that HOST_BITS_PER_WIDE_INT == 32, and in an
INTEGER_CST, all HOST_BITS_PER_WIDE_INT matter.

Richard