Anyone have any experience with __int128 for g++ or clang?

[Daniel]

Compiling on travis using g++ 4.8 and above (up to 8), and clang 3.8 and above (up to 6), on x64 and Ubuntu, I see std::numeric_limits<__int128>::is_specialized evaluate to false (unexpected.)

On the other hand, using clang xcode 6.4 and above, I see std::numeric_limits<__int128>::is_specialized evaluate to true (as expected.)

I'm fairly sure all of the tests should evaluate to true. Any suggestions why I'm getting these results welcome. (Or referral to a more appropriate group.)

Daniel

[Öö Tiib]

I remember there were some discussions about it few years ago.
Perhaps in some of gcc mailing lists.

My understanding of it was such that when the __int128 was introduced
it was not extended integer type at first. Reason was that the compiler
that had (and used) it could not immediately follow all requirements
that standards imposed upon extended integer types. Once the support
was implemented to comply with requirements it was made into extended
integer type too.

I'm not saying that you should take it at face value ... perhaps you
can search the archives. https://gcc.gnu.org/lists.html

[David Brown]

IIRC there were a few things that made them reluctant to classify
__int128 as an extended integer type - no integer constant suffix and no
printf/scanf support. I don't think these are required by the standard,
but would be something users would want.

But if gcc declared __int128 to be an extended integer type, then
maxint_t would have to be changed to 128-bit, and that could easily
break existing code and ABIs.

That does not stop you using the type, merely that it is a "compiler
extension" and not an "extended integer type" as described in the standards.

[Daniel]

On Tuesday, October 9, 2018 at 4:53:53 PM UTC-4, Öö Tiib wrote:
> On Tuesday, 9 October 2018 23:05:08 UTC+3, Daniel wrote:
> > Compiling on travis using g++ 4.8 and above (up to 8), and clang 3.8 and above (up to 6), on x64 and Ubuntu, I see std::numeric_limits<__int128>::is_specialized evaluate to false (unexpected.)
> >
>

> I remember there were some discussions about it few years ago.
> Perhaps in some of gcc mailing lists.
>
> My understanding of it was such that when the __int128 was introduced
> it was not extended integer type at first. Reason was that the compiler
> that had (and used) it could not immediately follow all requirements
> that standards imposed upon extended integer types. Once the support
> was implemented to comply with requirements it was made into extended
> integer type too.
>

Thanks for the pointer.

Following up on that, it seems that the g++ std::numeric_limits
specializations for __int128 are not defined when __STRICT_ANSI__ is defined,
which is the case when code is compiled with -std=c++NN rather than -
std=gnu++NN.

Given the existence of a 128 bit integer type, all I need is min() and max().
So a second question: would it be save to forgo std::numeric_limits and rely
on something like

template<typename T>
struct integer_traits
{
static const T __min = (((T)(-1) < 0) ?
(T)1 << (sizeof(T) * 8 - ((T)(-1) < 0)) : (T)0);
static const T __max = (((T)(-1) < 0) ?
(((((T)1 << ((sizeof(T) * 8 - ((T)(-1) < 0)) - 1)) - 1) << 1) + 1) : ~(T)0);
};

Thanks,
Daniel