Date: Wed, 26 Nov 2025 09:52:21 -0800
On Wednesday, 26 November 2025 08:04:47 Pacific Standard Time David Brown
wrote:
> How implementations /should/ behave, and how they /actually/ behave, is
> not always the same thing. For an implementation that is new to _BitInt
> and also new to int128_t, it is entirely conceivable that int128_t be
> handled by specific treatment in the manner of other standard integer
> types, while all _BitInt(N) types are handled by generic code for N
> bits. That could mean _BitInt(N) types that could be handled more
> efficiently, are handled correctly but inefficiently. We can hope that
> such implementations will be few, or only temporary in nature, but they
> are certainly a possibility.
I would consider that a serious QoI problem, as I said before. Any user of
such compiler should complain that the implementations are different. As you
said, it will likely be temporary, and therefore users should not need to
worry.
The Standard does not need to care either. We can assume implementations are
of quality.
> It is also entirely plausible that some implementations will support
> int128_t but not support _BitInt - again, that would hopefully only be a
> temporary thing. Many current compilers support some kind of 128-bit
> integer as an extension without having _BitInt support, so all they need
> in order to support a standardised int128_t is a typedef in their
> <cstdint> file.
This is different, because the issue it not _BitInt(128), but all the other
sizes, including those smaller than 128. Implementing 128-bit integer support
in GCC was a simple extension of the 64-bit support that already existed for
32-bit platforms. That's why it's only currently present in 64-bit platforms.
> I haven't checked the latest proposals for _BitInt in C++, but in C23,
> an implementation does not need to support bit sizes beyond that of
> "long long int" - that would still leave a need (or at least, a use) of
> int128_t. Again, I hope that compilers choose to support larger _BitInt
> types.
No, but it needs to support smaller ones that aren't a power of 8 either,
like _BitInt(9). That requires extra code and runtime implementation.
wrote:
> How implementations /should/ behave, and how they /actually/ behave, is
> not always the same thing. For an implementation that is new to _BitInt
> and also new to int128_t, it is entirely conceivable that int128_t be
> handled by specific treatment in the manner of other standard integer
> types, while all _BitInt(N) types are handled by generic code for N
> bits. That could mean _BitInt(N) types that could be handled more
> efficiently, are handled correctly but inefficiently. We can hope that
> such implementations will be few, or only temporary in nature, but they
> are certainly a possibility.
I would consider that a serious QoI problem, as I said before. Any user of
such compiler should complain that the implementations are different. As you
said, it will likely be temporary, and therefore users should not need to
worry.
The Standard does not need to care either. We can assume implementations are
of quality.
> It is also entirely plausible that some implementations will support
> int128_t but not support _BitInt - again, that would hopefully only be a
> temporary thing. Many current compilers support some kind of 128-bit
> integer as an extension without having _BitInt support, so all they need
> in order to support a standardised int128_t is a typedef in their
> <cstdint> file.
This is different, because the issue it not _BitInt(128), but all the other
sizes, including those smaller than 128. Implementing 128-bit integer support
in GCC was a simple extension of the 64-bit support that already existed for
32-bit platforms. That's why it's only currently present in 64-bit platforms.
> I haven't checked the latest proposals for _BitInt in C++, but in C23,
> an implementation does not need to support bit sizes beyond that of
> "long long int" - that would still leave a need (or at least, a use) of
> int128_t. Again, I hope that compilers choose to support larger _BitInt
> types.
No, but it needs to support smaller ones that aren't a power of 8 either,
like _BitInt(9). That requires extra code and runtime implementation.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2025-11-26 17:52:28
