Strange value of `BITINT_MAXWIDTH` in 16-bit platforms

[alejandro-colomar]

Hi!

@ThePhD claimed that BITINT_MAXWIDTH is (way way) larger than INT_MAX in 16-bit platforms in Clang, which was used as a base for the design choices of some C23 <stdbit.h> type-generic macros.

Is Clang really able to use integers of 1 MiB in 16-bit systems? Could you please confirm if that claim is true and if it actually works?

Cheers,
Alex

[frederick-vs-ja]

I don't know whether Clang supports any 16-bit platform.

[alejandro-colomar]

@ThePhD could you please comment?

[ThePhD]

People have been putting Clang on 16-bit system for over a decade now, after people spent time identifying places that did not work and were hardcoded (old LLVM discussion: https://discourse.llvm.org/t/thoughts-about-n-bit-bytes-for-clang-llvm/13862).

Some people even talk/write about it in detail:

https://archive.fosdem.org/2017/schedule/event/llvm_16_bit/ - https://www.embecosm.com/2017/04/18/non-8-bit-char-support-in-clang-and-llvm/

We're welcome to plug our ears and go "lalalalalala" and pretend it doesn't exist because it's not officially part of the repository, but I feel that it is ill-advised for C. I'm also not sure why we're pinging me on an issue of LLVM instead of just taking a survey of the ecosystem itself; there's plenty of vendors of 16-bit chips today, and you could just e-mail them. GCC and Clang both stopped officially building support for non CHAR_BIT == 8 platforms ages ago (I don't think Clang ever started), but people still patch both of these distributions as well as roll their own compilers.

Finally, the code for LLVM is clear in that they currently generally support up to 128, and up to the maxwidth value (e.g. well beyond 65 KiB), with the intent that they will crank it up to the max value once code generation bugs are fully solved:

https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/TargetInfo.h#L668-L680

Here is the override for X86-64 platforms:
https://github.com/llvm/llvm-project/blob/main/clang/lib/Basic/Targets/X86.h#L813-L815

I expect other platforms to do similarly, regardless of their CHAR_BIT size, if they support the necessary code generation.

[alejandro-colomar]

Hi @ThePhD,

People have been putting Clang on 16-bit system for over a decade now, after people spent time identifying places that did not work and were hardcoded (old LLVM discussion: https://discourse.llvm.org/t/thoughts-about-n-bit-bytes-for-clang-llvm/13862).

Some people even talk/write about it in detail:

https://archive.fosdem.org/2017/schedule/event/llvm_16_bit/ - https://www.embecosm.com/2017/04/18/non-8-bit-char-support-in-clang-and-llvm/

We're welcome to plug our ears and go "lalalalalala" and pretend it doesn't exist because it's not officially part of the repository, but I feel that it is ill-advised for C.

I didn't do that. I was just asking, because I have no idea. I exclusively program for amd64 (and arm64 in the past, but not anymore), so you can expect that my knowledge about that is rather low.

I'm also not sure why we're pinging me on an issue of LLVM instead of just taking a survey of the ecosystem itself; there's plenty of vendors of 16-bit chips today, and you could just e-mail them.

• I don't know of such vendors. (Again, no experience with 16-bit chips.)
• Finding vendors that already support _BitInt is going to be tough. Even GCC still doesn't support it (at least 14, which is what I have in Debian Sid), so I expect smaller compilers to go slower. Since Clang was the origin of the feature, I expect it to be more mature.
• You were the one that mentioned Clang in the first place, so I asked about it. At first, I asked you to provide an example of a shell session calling Clang with the flags necessary for reproducing that, but since you didn't reply, I had to go to Clang to ask.

If you don't mind, I would like to see some invocation of Clang, regardless of it being a fork of it, doing this:

$ printf '#include <limits.h>\nBITINT_MAXWIDTH\n' | clang -std=c23 -E -x c - | tail -n1
8388608

but with the appropriate flags for compiling for a 16-bit arch. And then, if that value is greater than INT_MAX and PTRDIFF_MAX, I would appreciate if you can give me the email of the maintainer of the fork, to ask if they just forgot to fix that detail, or if they really expect it to work, and how.

Extra points if you manage to run a program using such a huge _BitInt, but I expect you maybe don't have such a device with you.

GCC and Clang both stopped officially building support for non CHAR_BIT == 8 platforms ages ago (I don't think Clang ever started), but people still patch both of these distributions as well as roll their own compilers.

I think CHAR_BIT has not much to do with _BitInt.

Finally, the code for LLVM is clear in that they currently generally support up to 128, and up to the maxwidth value (e.g. well beyond 65 KiB),

Where is the value of BITINT_MAXWIDTH defined within LLVM source code?

Which itself I expect to be the question: Where is llvm::IntegerType::MAX_INT_BITS defined in LLVM?

Maybe it's here?:

llvm/include/llvm/IR/DerivedTypes.h:53:    MAX_INT_BITS = (1<<23)   ///< Maximum number of bits that can be specified

Do the forks for 16-bit archs keep that value? That's most likely a bug in the fork.

with the intent that they will crank it up to the max value once code generation bugs are fully solved:
https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/TargetInfo.h#L668-L680

What do you mean by "the max value"? BITINT_MAXWIDTH of 1 MiB? Or beyond? If it's 1 MiB I guess that's expected.

Here is the override for X86-64 platforms: https://github.com/llvm/llvm-project/blob/main/clang/lib/Basic/Targets/X86.h#L813-L815

I don't understand. What does it override? I can't read the Clang source code too much. I don't speak C++.

I expect other platforms to do similarly, regardless of their CHAR_BIT size, if they support the necessary code generation.

[frederick-vs-ja]

Is Clang really able to use integers of 1 MiB in 16-bit systems? Could you please confirm if that claim is true and if it actually works?

Well, I don't think this can ever be supported.

I guess the only thing left to do here is rejecting too large values for -fexperimental-max-bitint-width and MaxBitIntWidth on 16-bit platforms with suitable error messages.

[thesamesam]

Finding vendors that already support _BitInt is going to be tough. Even GCC still doesn't support it (at least 14, which is what I have in Debian Sid),

No, it does. See https://gcc.gnu.org/gcc-14/changes.html.

[alejandro-colomar]

Finding vendors that already support _BitInt is going to be tough. Even GCC still doesn't support it (at least 14, which is what I have in Debian Sid),

No, it does. See https://gcc.gnu.org/gcc-14/changes.html.

Hmmm, thanks for the correction. I probably forgot to add -std=c23 in my experiment...

Nevertheless, the limit of GCC is too low, and thus can't be used for checking this.

$ printf '#include <limits.h>\nBITINT_MAXWIDTH\n' | gcc -std=c23 -Wall -Wextra -E -x c - | tail -n1
65535

If GCC has such a low limit, I expect every other (non-Clang) compiler to be no better.

[pinskia]

Nevertheless, the limit of GCC is too low, and thus can't be used for checking this.

$ printf '#include <limits.h>\nBITINT_MAXWIDTH\n' | gcc -std=c23 -Wall -Wextra -E -x c - | tail -n1
65535
If GCC has such a low limit, I expect every other (non-Clang) compiler to be no better.

From:
https://inbox.sourceware.org/gcc-patches/ZNPXdkEC7m01caOV@tucnak/

The reason why it is max 64k for GCC:

And if that is overcome, then we have limitation
of TYPE_PRECISION being 16-bit, so 65535 as maximum precision.  Perhaps
we could make TYPE_PRECISION dependent on BITINT_TYPE vs. others and use
32-bit precision in that case later.  Latest Clang/LLVM I think supports
on paper up to 8388608 bits, but is hardly usable even with much shorter
precisions.

So GCC decided to stay with max 16bits of precision (aka 64k).

[alejandro-colomar]

Nevertheless, the limit of GCC is too low, and thus can't be used for checking this.
$ printf '#include <limits.h>\nBITINT_MAXWIDTH\n' | gcc -std=c23 -Wall -Wextra -E -x c - | tail -n1
65535
If GCC has such a low limit, I expect every other (non-Clang) compiler to be no better.

From: https://inbox.sourceware.org/gcc-patches/ZNPXdkEC7m01caOV@tucnak/

The reason why it is max 64k for GCC:

And if that is overcome, then we have limitation
of TYPE_PRECISION being 16-bit, so 65535 as maximum precision.  Perhaps
we could make TYPE_PRECISION dependent on BITINT_TYPE vs. others and use
32-bit precision in that case later.  Latest Clang/LLVM I think supports
on paper up to 8388608 bits, but is hardly usable even with much shorter
precisions.

So GCC decided to stay with max 16bits of precision (aka 64k).

Hi @pinskia !

I don't think that was a bad choice. That's definitely enough for my use cases.

I was just wondering about the self-consistency of limits, rather than complaining that certain limits are too low. In fact, the problem is in some forks of Clang, where the limits are too high, and they result in broken code (most likely; I haven't tried such a fork, and @ThePhD didn't confirm nor deny).

On the other hand, it's interesting that GCC claims that Clang's limits are fictional to some extent.

Cheers,
Alex