Re: 3.4BIB HOST_WIDE_INT size error

Re: 3.4BIB HOST_WIDE_INT size error

[Nathanael Nerode]

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

Re: 3.4BIB HOST_WIDE_INT size error

[Zack Weinberg]

Nathanael Nerode <neroden@twcny.rr.com> writes:

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

It does indeed serve several different purposes.

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

It was before my time but I believe that was the original function of
HOST_WIDE_INT.

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

My plan is to annotate the 64-bit targets in config.gcc and use that
to set the required size of HOST_WIDE_INT in auto-host.h; then hwint.h
won't have a tm.h dependence.  Since this is a blocker for the b-i
merge, I intend to do it tomorrow morning (I'm a bit too tired to
handle it now).

zw

Re: 3.4BIB HOST_WIDE_INT size error

[Alexandre Oliva]

On Dec 14, 2002, Zack Weinberg <zack@codesourcery.com> wrote:

> My plan is to annotate the 64-bit targets in config.gcc and use that
> to set the required size of HOST_WIDE_INT in auto-host.h

Please don't!  We'd be going back to the way it was before, that
introduced only some subtle problems in the testsuite of 32x64 ports.
Problems that would only be found after a lot of testing and
bug-fixing had already been done, and after fixing it, you'd have to
retest a lot.

Instead, I suggest introducing a configure-like preprocessor test in
the Makefile that derives the HOST_WIDE_INT width information from the
target header files and generates a new header file that defines
macros to tell hwint.h what to do.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: 3.4BIB HOST_WIDE_INT size error

[Kai Henningsen]

neil@daikokuya.co.uk (Neil Booth)  wrote on 14.12.02 in <20021214095357.GA534@daikokuya.co.uk>:

> Nathanael Nerode wrote:-
>
> > 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.
>
> In 3.3., CPP already gets this stuff right.  It just doesn't handle the
> case where the widest target int is strictly greater than twice the
> widest host int.  Since this is almost never the case, I didn't deem
> it worthwhile doing truly MP stuff.
>
> However, if we do go to arbitrary arithmetic, which would be nice
> aestetically at least, we *must not* impact the performance of native
> compiles.  Since all this is theoretically determinable at build
> time, there should be no run-time performance hit for handling native
> efficiently, and crosses less efficiently if the target types make
> that necessary.
>
> > Maybe I'll put this on the beginner projects list, since it's another
> > BUILD/HOST/TARGET confusion issue.
>
> I think if you can solve these issues you're a bit more advanced than
> "beginner" 8-)

Hmm ... I'd think there could be three (possibly four) sets of routines  
(possibly fastest host int, widest host int, twice widest host int, N  
times some (possibly widest) host int), and a little preprocessor magic  
could chose the right ones for every job. That part at least doesn't sound  
all that hard.

Figuring out which jobs exist, and what their constraints are, is of  
course harder.

MfG Kai

Re: 3.4BIB HOST_WIDE_INT size error

[Neil Booth]

Nathanael Nerode wrote:-

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

In 3.3., CPP already gets this stuff right.  It just doesn't handle the
case where the widest target int is strictly greater than twice the
widest host int.  Since this is almost never the case, I didn't deem
it worthwhile doing truly MP stuff.

However, if we do go to arbitrary arithmetic, which would be nice
aestetically at least, we *must not* impact the performance of native
compiles.  Since all this is theoretically determinable at build
time, there should be no run-time performance hit for handling native
efficiently, and crosses less efficiently if the target types make
that necessary.

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

I think if you can solve these issues you're a bit more advanced than
"beginner" 8-)

Neil.

Re: 3.4BIB HOST_WIDE_INT size error

[Zack Weinberg]

Nathanael Nerode <neroden@twcny.rr.com> writes:

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

This solution requires almost as much work as the proper fix, because
the assumption that target integers are represented with exactly two
whatevers is pervasive.

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

This is an interesting idea but doesn't achieve my immediate goal.
HOST_WIDE_INTs are imbedded in both tree and RTX structures.
Renaming them TARGET_WIDE_INT doesn't get rid of their target
dependence (just makes it explicit).  My goal is to not require tm.h
for tree.h or rtl.h, because we won't be able to remove the
#include "tm.h" from many .c files if both tree.h and rtl.h need it.

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

Not a bad idea.  You might suggest clearing up the CONST_DOUBLE
confusion too; that's a related problem (sometimes CONST_DOUBLE is
used for floating point constants and sometimes it's used for integers
too big for CONST_INT).

zw

Re: 3.4BIB HOST_WIDE_INT size error

[Nathanael Nerode]

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

Re: 3.4BIB HOST_WIDE_INT size error

[Zack Weinberg]

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

3.4BIB HOST_WIDE_INT size error

[David Edelsohn]

	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.

David