Tests fail when compiling without GNU extensions

[mjerabek]

Description

When compiling libfmt with gcc/clang with GNU extensions disabled, format-test fails while formatting __int128_t values. It appears they are treated just as ints.

As __int128_t is a GNU extension, I don't expect it to work, but it should not be used/tested in this case. However, even with GNU extensions disabled, __int128_t is defined and appears to work, but it is not formatted right. I did not find any obvious errors in the code - as far as I can tell, it should work, yet it doesn't.

How to reproduce

$ cmake -Bbuild -H. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_EXTENSIONS=OFF
$ cmake --build build
$ cd build && ctest --output-on-failure
[...]
[ RUN      ] FormatterTest.FormatDec
../test/format-test.cc:1120: Failure
Value of: format("{0}", static_cast<__int128_t>((9223372036854775807L)) + 1)
  Actual: "0"
Expected: "9223372036854775808"
../test/format-test.cc:1122: Failure
Value of: format("{0}", static_cast<__int128_t>((-9223372036854775807L-1)) - 1)
  Actual: "4294967295"
Expected: "-9223372036854775809"
[...]
[  FAILED  ] FormatterTest.FormatDec (0 ms)
[ RUN      ] FormatterTest.FormatHex
../test/format-test.cc:1161: Failure
Value of: format("{0:x}", static_cast<__int128_t>((9223372036854775807L)) + 1)
  Actual: "0"
Expected: "8000000000000000"
../test/format-test.cc:1163: Failure
Value of: format("{0:x}", static_cast<__int128_t>((-9223372036854775807L-1)) - 1)
  Actual: "ffffffff"
Expected: "-8000000000000001"
[...]
[==========] 115 tests from 12 test cases ran. (14 ms total)
[  PASSED  ] 112 tests.
[  FAILED  ] 3 tests, listed below:
[  FAILED  ] FormatterTest.FormatDec
[  FAILED  ] FormatterTest.FormatHex
[  FAILED  ] FormatterTest.FormatOct

Alternatively, this is reproducible on godbolt: https://godbolt.org/z/XGg8yy

[vitaut]

Compiling tests in this configuration is not supported at the moment but a PR that makes it possible would be welcome.

[vitaut]

As it turned out numeric_limits is broken for 128-bit integer types. Worked around in d39d661. Thanks for reporting.

[BillyDonahue]

I know this is closed, but FTR numeric_limits is not technically broken here.
It's just that __uint128_t is not an arithmetic type, and numeric_limits is specialized only for arithmetic types.

https://gcc.godbolt.org/z/vM5nPE

Because if it WAS an arithmetic type, then std::maxint_t would have to expand to include it, and that would break ABI somewhere.

[vitaut]

You are right about ABI. __uint128_t should be an arithmetic type but numeric_limits is an unfixable mess because of ABI.