This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] HOST_WIDE_INT transition steps
- From: Richard Sandiford <rsandifo at linux dot vnet dot ibm dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Eric Botcazou <ebotcazou at adacore dot com>, Richard Biener <rguenther at suse dot de>, <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 22 May 2014 12:24:09 +0100
- Subject: Re: [RFC] HOST_WIDE_INT transition steps
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1405191434420 dot 13304 at zhemvz dot fhfr dot qr> <8868910 dot XnRXJS3iKK at polaris> <alpine dot LSU dot 2 dot 11 dot 1405201310260 dot 13304 at zhemvz dot fhfr dot qr> <1768416 dot XG1yqiIQrU at polaris> <Pine dot LNX dot 4 dot 64 dot 1405201505570 dot 29858 at digraph dot polyomino dot org dot uk>
"Joseph S. Myers" <firstname.lastname@example.org> writes:
> On Tue, 20 May 2014, Eric Botcazou wrote:
>> > Make the code base easier to understand for newcomers. It's also a
>> > documentation improvement (you see what a HOST_WIDE_INT really is),
>> > alongside with [u]int64_t being less to type ...
>> I personally find the abstraction and the separation with the other, more
>> mundane types useful, but I guess that it's a matter of habit.
> Whatever the abstraction is, HOST_WIDE_INT is a pretty poor name for it.
> I think it's something like "integer type that is big enough to store a
> target address / offset in bytes, or a target word", together with a sense
> of "integer type big enough for certain constants and such that twice it
> is big enough for other constants" (the latter being what wide-int should
> enable eliminating eventually).
> But I suspect HOST_WIDE_INT is used for lots of other things as well - and
> for things for which 64 bits may not be enough (bit offsets, for example),
> and for that matter int is used for things for which HOST_WIDE_INT would
> be more appropriate (the length of a STRING_CST, for example). So while
> there may be a meaningful abstraction somewhere in there, I don't think
> the particular places that happen to use HOST_WIDE_INT are a very good
> guide to where such an abstraction should be used - and don't think moving
> to int64_t / uint64_t would actually lose information of use for cleaning
> things up in future.
Same here FWIW. And int64_t and uint64_t have the advantage of being
"proper" types rather than #defines, which has caused surprises in the past.
(E.g. a case where HOST_WIDE_INT (x) worked for most hosts but not mingw64.)
We wouldn't be able to get away from using the #define without also
replacing "unsigned HOST_WIDE_INT" with something else, which wouldn't
be much less invasive than replacing all HOST_WIDE_INTs. And I can't
help thinking that people have used HOST_WIDE_INT not because they
needed a signed type with undefined overflow, but because it was less