Re: HOST_WIDE_INT, preprocessing, and MIPS

[Dave Brolley <brolley at cygnus dot com>]

Jeff is correct. Kaveh was going to change things to use HOST_WIDEST_INT. I don't
know if he did that yet.

Dave

Jeffrey A Law wrote:

>   In message <199812190243.SAA31880@adsl-206-170-148-33.dsl.pacbell.net>you wri
> te:
>   >
>   > Folks --
>   >
>   >   On 64-bit mips the preprocessor turns out to be quite severely
>   > broken.  In particular, the following program:
>   >
>   >   #if (1L << 32)
>   >   x
>   >   #endif
>   >
>   > yields:
>   >
>   >   > g++ -mabi=64 -E test.c
>   >   # 1 "test.c"
>   >
>   > after preprocessing.  But, since a long is 64-bits in this
>   > environment, this should not occur.
> This is something Zack, Paul, Dave (and possibly others) are working to
> resolve.  It ought to be nailed down reasonably soon.
>
>   >   One possibility is to make HOST_WIDE_INT wider than 32-bits.  But, I
>   > bet this will cause problems in lots of places.
> Not as many as one might think -- I've already fixed most problems exposed by
> such changes.  But we're taking a different approach.
>
> The preprocessor should be using the widest integer type available for most
> of its calculations.  So we're in the process of creating HOST_WIDEST_INT
> for use by the preprocessor (and possibly other code).
>
>   >   Also, there was discussion recently about removing the use of
>   > inttypes.h from the definition of HOST_WIDE_INT.  I think this
>   > examples shows that it *must* be present.  Since the preprocessor
>   > doesn't know about the object model, it must use the widest type
>   > available on the platform, period.
> It is not necessary to use inttypes.h for this.  It's easy enough for
> autoconf to determine the widest integer supported by the host and
> arrange for a suitable HOST_WIDEST_INT definition.
>
> jeff