Re: 3.4BIB HOST_WIDE_INT size error

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

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

>For this, the common definition is a pair of HOST_WIDE_INTs.  And that
>is where the target dependence comes in, because when we're targeting
>a 64-bit system we need that pair to be 128 bits wide, but on a 32-bit
>host HOST_WIDE_INT is normally 32 bits.
>
>The proper fix is to introduce a multi-precision library to be used
>for constant integers in both tree and RTL, but this would be an
>insanely invasive change.

The lazy-proper fix (if I can call it that?) is to introduce a 
single-precision library for constant integers in tree, RTL, and cpp.  
Just *one* type: TARGET_LONG_LONG or something like that.  
Suppose we need a 128-bit type and we're on a 16-bit system with long 
being 32 bits?  Then we need four longs... so this is already a bit 
messy to implement.

The slightly lazier proper fix (but still kind of invasive) is to simply 
introduce TARGET_WIDE_INT, and split all current uses of HOST_WIDE_INT 
into two categories, those requiring TARGET_WIDE_INT and those which are 
really HOST_WIDE_INT.  To be on the safe side, I'd start by making 
everything use TARGET_WIDE_INT, and then back-convert them one at a 
time.  

This would at least have the advantage of separating out the two cases 
clearly, so that some later person implementing the single 
precision or multiprecision library wouldn't have to wade through all 
the cases which really *are* host numbers...

Maybe I'll put this on the beginner projects list, since it's another 
BUILD/HOST/TARGET confusion issue.

--Nathanael