Date: Fri, 12 Sep 2025 11:01:54 +0200
When compiling the code below with
clang -std=c23 bitint.c -o bitint && ./bitint
I get on Mac OS:
arm64: _BitInt(128) uses 16 bytes in memory and aligns to 16 bytes.
x86_64: _BitInt(8388608) uses 1048576 bytes in memory and aligns to 8 bytes.
Here, the alignment on arm64 is 16 bytes, which is higher than the 8 bytes for a 64-bit platform.
-- bitint.c --
#include <stdio.h>
#include <limits.h>
int main()
{
printf("_BitInt(%d) uses %lu bytes in memory and aligns to %lu bytes.\n",
BITINT_MAXWIDTH,
sizeof(_BitInt(BITINT_MAXWIDTH)),
alignof(_BitInt(BITINT_MAXWIDTH))
);
return 0;
}
clang -std=c23 bitint.c -o bitint && ./bitint
I get on Mac OS:
arm64: _BitInt(128) uses 16 bytes in memory and aligns to 16 bytes.
x86_64: _BitInt(8388608) uses 1048576 bytes in memory and aligns to 8 bytes.
Here, the alignment on arm64 is 16 bytes, which is higher than the 8 bytes for a 64-bit platform.
-- bitint.c --
#include <stdio.h>
#include <limits.h>
int main()
{
printf("_BitInt(%d) uses %lu bytes in memory and aligns to %lu bytes.\n",
BITINT_MAXWIDTH,
sizeof(_BitInt(BITINT_MAXWIDTH)),
alignof(_BitInt(BITINT_MAXWIDTH))
);
return 0;
}
-- > On 11 Sep 2025, at 22:52, Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> wrote: > > You touched another problematic point. > > The problem is this already exists in C, and the proposal is it shouldn't be incompatible. So, whatever C is doing today C++ should do the same. > What C does on x86_64 right now is alignof(_BitInt(512)) = 8. > > If in the future Intel comes up with an extension that would allow arithmetic to take place in 512bit AVX registers, and would allow for direct operations on memory but only aligned on a 64byte boundary, then > alignof(_BitInt(512)) would still be 8, and _BitInt(512) would be unable to use it because the ABI has already been defined and libraries using it already exist. > > It's just another nail. >
Received on 2025-09-12 09:02:09