HOST_WIDE_INT, preprocessing, and MIPS
Mon Jan 4 12:00:00 GMT 1999
Jeff is correct. Kaveh was going to change things to use HOST_WIDEST_INT. I don't
know if he did that yet.
Jeffrey A Law wrote:
> In message <199812190243.SAA31880@adsl-206-170-148-33.dsl.pacbell.net>you wri
> > 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.
More information about the Gcc-bugs