inttypes.h on x86-64

["Neal H. Walfield" <neal at walfield dot org>]

I'm using newlib on my OS, which I am porting to x86-64.  When using
Newlib's inttypes.h file, I get, what I think are, gratuitous
warnings.  I think this is because in libc/include/stdint.h, newlib
defines int64_t and uint64_t as follows:

  #if __have_long64
  typedef signed long int64_t;
  typedef unsigned long uint64_t;
  #define __int64_t_defined 1
  #elif __have_longlong64
  typedef signed long long int64_t;
  typedef unsigned long long uint64_t;
  #define __int64_t_defined 1
  #elif  __STDINT_EXP(INT_MAX) > 0x7fffffff
  typedef signed int int64_t;
  typedef unsigned int uint64_t;
  #define __int64_t_defined 1
  #endif

however, libc/include/inttypes.h reverses the if:

  /* 64-bit types */
  #if __have_longlong64
  #define __PRI64(x) __STRINGIFY(ll##x)
  #define __SCN64(x) __STRINGIFY(ll##x)
  #elif __have_long64
  #define __PRI64(x) __STRINGIFY(l##x)
  #define __SCN64(x) __STRINGIFY(l##x)
  #else
  #define __PRI64(x) __STRINGIFY(x)
  #define __SCN64(x) __STRINGIFY(x)
  #endif

As both __have_long64 and __have_longlong64 are defined as one
(according to gcc -E -dM), this means that the standard 64-bt types
are longs but "ll" format modifier is used.

I experienced this problem using Newlib 1.16.0, however, I have
visually confirmed that this is also the case for current cvs.

Glibc appears to use long for uint64_t on 64-bit systems (i.e, the
same as newlib).  Thus, I suspect that the right change is to
rearrange the if's in <inttypes.h>.

Thanks,
Neal