HOST_WIDE_INT, preprocessing, and MIPS

[Jeffrey A Law]

  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