XPost: comp.arch

On Mon, 04 Aug 2025 12:09:32 GMT
[email protected] (Anton Ertl) wrote:

Michael S <[email protected]> writes:

Actually, in our world the latest C standard (C23) has them, but the >spelling is different: _BitInt(32) and unsigned _BitInt(32).
I'm not sure if any major compiler already has them implemented. Bing >copilot says that clang does, but I don't tend to believe eveything
Bing copilot says.

I asked godbolt, and tried the following program:

It turned out that I didn't need even goldbolt.
I already had sufficiently advanced gcc and clang installed on my new
Windows PC at work. I probably have them installed on very old home PC
as well, but now I am at work. Playing with compilers instead of
working.

typedef ump unsigned _BitInt(65535);

ump sum3(ump a, ump b, ump c)
{
return a+b+c;
}

and for the C setting gcc-15.1 AMD64 produces 129 lines of assembly
language code; for C++ it complains about the syntax. For 65536 bits,
it complains about being beyond the maximum number of 65535 bits.

For the same program with the C setting clang-20.1 produces 29547
lines of assembly language code; that's more than 28 instructions for
every 64-bit word of output, which seems excessive to me, even if you
don't use ADX instructions (which clang apparently does not); I expect
that clang will produce better code at some point in the future.
Compiling this function also takes noticable time, and when I ask for
1000000 bits, clang still does complain about too many bits, but
godbolt's timeout strikes; I finally found out clang's limit: 8388608
bits. On clang-20.1 the C++ setting also accepts this kind of input.

Followups set to comp.arch.

- anton

I didn't pay much attention to code size yet. Had seen two other
worrying things.

1. Both gcc and clang happily* accept _BitInt() syntax even when
-std=c17 or lower. Is not here a potential name clash for existing
sources that use _BitInt() as a name of the function? I should think
more about it.

2. Windows-specific.
gcc and clang appear to have different ABIs for return value of type _BitInt(128).


* - the only sign of less than perfect happiness is a warning produced
with -pedantic flag.


Cross-posted to c.lang.c

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.arch

On Mon, 04 Aug 2025 09:53:51 -0700
Keith Thompson <[email protected]> wrote:

Michael S <[email protected]> writes:

On Mon, 04 Aug 2025 12:09:32 GMT
[email protected] (Anton Ertl) wrote:

[...]

typedef ump unsigned _BitInt(65535);

The correct syntax is :

typedef unsigned _BitInt(65535) ump;

ump sum3(ump a, ump b, ump c)
{
return a+b+c;
}

[...]

1. Both gcc and clang happily* accept _BitInt() syntax even when
-std=c17 or lower. Is not here a potential name clash for existing
sources that use _BitInt() as a name of the function? I should think
more about it.

In C17 and earlier, _BitInt is a reserved identifier. Any attempt to
use it has undefined behavior. That's exactly why new keywords are
often defined with that ugly syntax.

That is language lawyer's type of reasoning. Normally gcc maintainers
are wiser than that because, well, by chance gcc happens to be widely
used production compiler. I don't know why this time they had chosen
less conservative road.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.arch

On 2025-08-04 15:03, Michael S wrote:

On Mon, 04 Aug 2025 09:53:51 -0700
Keith Thompson <[email protected]> wrote:

...

In C17 and earlier, _BitInt is a reserved identifier. Any attempt to
use it has undefined behavior. That's exactly why new keywords are
often defined with that ugly syntax.

That is language lawyer's type of reasoning. Normally gcc maintainers
are wiser than that because, well, by chance gcc happens to be widely
used production compiler. I don't know why this time they had chosen
less conservative road.

If _BitInt is accepted by older versions of gcc, that means it was
supported as a fully-conforming extension to C. Allowing implementations
to support extensions in a fully-conforming manner is one of the main
purposes for which the standard reserves identifiers.
If you thought that gcc was too conservative to support extensions, you
must be thinking of the wrong organization.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.arch

On Mon, 4 Aug 2025 15:25:54 -0400
James Kuyper <[email protected]> wrote:

On 2025-08-04 15:03, Michael S wrote:

On Mon, 04 Aug 2025 09:53:51 -0700
Keith Thompson <[email protected]> wrote:

...

In C17 and earlier, _BitInt is a reserved identifier. Any attempt
to use it has undefined behavior. That's exactly why new keywords
are often defined with that ugly syntax.

That is language lawyer's type of reasoning. Normally gcc
maintainers are wiser than that because, well, by chance gcc
happens to be widely used production compiler. I don't know why
this time they had chosen less conservative road.

If _BitInt is accepted by older versions of gcc, that means it was
supported as a fully-conforming extension to C. Allowing
implementations to support extensions in a fully-conforming manner is
one of the main purposes for which the standard reserves identifiers.
If you thought that gcc was too conservative to support extensions,
you must be thinking of the wrong organization.

I know that gcc supports extensions.
I also know that gcc didn't support *this particular extension* up
until quite recently. I would guess, up until this calendar year.
Introducing new extension without way to disable it is different from supporting gradually introduced extensions, typically with names that
start by double underscore and often starting with __builtin.

BTW, I still didn't think deeply about it and still hope that outside
of C23 mode gcc somehow cared to make name clash unlikely.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)