Re: 3.4BIB HOST_WIDE_INT size error

[Nathanael Nerode <neroden at twcny dot rr dot com>]

Zack wrote:
>David Edelsohn <dje@watson.ibm.com> writes:
>>
>>       And now the next problem...
>>
>>       With the tm.h files removed from config.h and bconfig.h, the 
sizes
>> of target types are not defined before system.h includes hwint.h.
>>
>> From hwint.h:
>>
>> # ifdef MAX_LONG_TYPE_SIZE
>> #  if MAX_LONG_TYPE_SIZE > HOST_BITS_PER_LONG
>>
>> Without tm.h, MAX_LONG_TYPE_SIZE is not defined, so HOST_WIDE_INT 
defaults
>> to "int" instead of "long long".  Building cross-compiler from 32-bit 
host
>> to 64-bit target fails.

>Augh yuck.  I *knew* the target dependence of the width of
>HOST_WIDE_INT was going to bite us eventually.
>
>I will fix this but I do not have time to do so now.
>
>zw

Goodness, HOST_WIDE_INT is used all over the place.  In fact, it 
looks like it might be serving several different purposes, though I'm
not sure.

I assumed we had:
* types for using internal to host parts of the compiler, which are 
simply guaranteed to be long enough for the compiler's own purposes.  
These might not be autoconf-determinable when build != host, but they 
should be entirely target-independent.

* types for representing values which should be target short, int, long, 
etc., for computing at compile time things which are "theoretically" 
computed at program run time by the program running on the target.  
(Such as for constant folding, preprocessor arithmetic, etc.)

I'm not sure what exactly HOST_WIDE_INT is supposed to be. If it's the 
type for representing a target type, it should be target-specific and be 
included after tm.h.

If it's really for representing a host type, it is incorrect for it to 
depend on anything target-specific, at all.

It looks to me like it's used *both* to hold target values up to the 
size of target 'long' *and* for some other internal host purposes.  
Which would be bad.

But I don't understand the code quite well enough to be sure.

--Nathanael