Definition of __(U)INT64_TYPE__ on riscv64 is inconsistent with other targets

[EdSchouten]

On 32-bit systems, Clang defines __INT64_TYPE__ and __UINT64_TYPE__ using long long:

$ i686-unknown-cloudabi-cc -dM -E - < /dev/null | grep INT64_TYPE
#define __INT64_TYPE__ long long int
#define __UINT64_TYPE__ long long unsigned int
$ armv6-unknown-cloudabi-eabihf-cc -dM -E - < /dev/null | grep INT64_TYPE
#define __INT64_TYPE__ long long int
#define __UINT64_TYPE__ long long unsigned int

On 64-bit systems, it chooses plain long instead, as this is the smallest primitive type that is sufficiently large:

$ x86_64-unknown-cloudabi-cc -dM -E - < /dev/null | grep INT64_TYPE
#define __INT64_TYPE__ long int
#define __UINT64_TYPE__ long unsigned int
$ aarch64-unknown-cloudabi-cc -dM -E - < /dev/null | grep INT64_TYPE      
#define __INT64_TYPE__ long int
#define __UINT64_TYPE__ long unsigned int

For RISC-V, we always use long long.

$ riscv32-unknown-cloudabi-cc -dM -E - < /dev/null | grep INT64_TYPE
#define __INT64_TYPE__ long long int
#define __UINT64_TYPE__ long long unsigned int
$ riscv64-unknown-cloudabi-cc -dM -E - < /dev/null | grep INT64_TYPE
#define __INT64_TYPE__ long long int
#define __UINT64_TYPE__ long long unsigned int

Though this is technically correct, I've seen some code break as a result of this, especially when code expects that uint64_t and size_t can be mixed on riscv64.

[asb]

Thanks for the report! GCC RISC-V also uses long int and long unsigned int for (u)int64 on RV64. I've been trying to match the GCC environment but must have missed this case. I'll fix and re-review the defines for any other unintended diffs in the morning.