default integer value limits to 128 bits with __int128 extensions, fix for [GH #38]

[mohitmishra786]

Fixes #38.

With a 128-bit host integer representation, MAX_INTEGER_VALUE, MIN_INTEGER_VALUE and MAX_UNSIGNED_INTEGER_VALUE stayed at their 64-bit values, so the overflow checks in const_ints.c rejected valid __int128 constant arithmetic ((__int128)1 << 100 times 4 gave "expression must have a constant value"). The macOS CMake configurations use this representation by default.

• targ_def.h: when INT128_EXTENSIONS_ALLOWED, the default limits are those of __int128_t / __uint128_t.
• defines_linux.h and the Linux base.cmakedef no longer hard-code the 64-bit limits, so changing the integer value types to the 128-bit types also changes the limits. The limits are only used when INTEGER_VALUE_REPR_IS_A_HOST_INTEGER is TRUE, and the default Linux builds use the array representation, so their behavior is unchanged.

Testing (Docker, linux-gcc-debug):

• A build with INTEGER_VALUE_REPR_IS_A_HOST_INTEGER=1 and the __int128 types reproduced the error before the change. After it, valid __int128 arithmetic is accepted and real overflows (MAX + 1, MIN / -1, MAX * 2, MIN * 2) are still diagnosed, the same as the default build.
• changes/ and all tests using __int128: no differences from the expectations in edg_x86_64 and edg_x86_64_cp.
• linux-i686-gcc-debug builds.

[mohitmishra786]

@wchilders-nvidia @nv-cmeerw @daveedvdv could you please review this PR

[mohitmishra786]

@nv-cmeerw @wchilders-nvidia could you please review this PR?

[nv-cmeerw]

Also needs at least a basic test case.

[nv-cmeerw]

Instead of referring to "macOS CMake configuraton", this should say which macro setting is responsible (I think it is INTEGER_VALUE_REPR_IS_A_HOST_INTEGER?)

[mohitmishra786]

Yes, it is INTEGER_VALUE_REPR_IS_A_HOST_INTEGER. The entry now says that when it is TRUE and __int128 extensions are allowed, the integer value types default to the 128-bit types but the limits stayed at 64 bits.

[nv-cmeerw]

This needs something like --gnu_version 150200 to make __int128 available (so say For example, with --gnu_version 150200:)

[mohitmishra786]

Done: "For example, with --gnu_version 150200:".

[nv-cmeerw]

That seems mostly redundant?

[mohitmishra786]

Agreed, it is now just "This is now fixed."

[mohitmishra786]

@nv-cmeerw added changes/GH38 (--gnu_version 150200). It checks __int128 constant arithmetic past 64 bits, and that overflow of the 128-bit range (max + 1, min / -1, max * 2, min * 2) is still diagnosed.

The default Linux configs use the array representation, where these limits are not used, so the test passes there with or without the change. With a build using INTEGER_VALUE_REPR_IS_A_HOST_INTEGER=1 and the __int128 types, main gets three spurious errors in this test and misses the min / -1 overflow; with this change it matches the recording.

The test has //require:INT128_EXTENSIONS_ALLOWED 1, since the i686 build has no __int128, and the edg_x86_32 / edg_x86_32_cp expectations list it as REQUIREMENTS NOT MET.

[nv-cmeerw]

Looks good to me now.

@wchilders-nvidia @daveedvdv-nvidia any other opinions?