Re: alignas (C11)

> On Nov 12, 2025, at 19:39, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> Here is another patch set to sprinkle some C11 features around the
> code. My aim is to make a little bit of use of several C11 features
> as examples and encouragement for future code, and to test compilers.
>
> Here, I'm proposing to make some use of the alignas specifier. This takes the place of compiler extensions such as __attribute__((aligned(a))) and __declspec(align(a)), packaged up as pg_attribute_aligned(a), which are used in a variety of places. Also, we can simplify some places where unions are used to encourage alignment, and remove a few workaround for lack of alignment attribute support.
>
> Some detail notes:
>
> - Technically, compilers are only required to support alignas up to (handwaving over some terminology) the largest alignment of a built-in type, so maybe 8 or 16. Support for larger alignments like alignas(PG_CACHE_LINE_SIZE) is implementation-defined. I have split up my patches so that fundamental and extended alignments are in separate patches, so this could be eased into, but I'm expecting that all compilers in practical use support alignments up to PG_IO_ALIGN_SIZE. (For MSVC, 4096 appears to be the actual limit by default, per [0], but this is independent of using alignas or __declspec. I haven't found any explicit documentation for clang or gcc.)
>
> [0]: https://learn.microsoft.com/en-us/cpp/build/reference/align-section-alignment?view=msvc-170
>
> - You cannot use alignas on a typedef. So some uses of the attribute pg_attribute_aligned() like for PgAioUringContext or the whole int128 business cannot be converted directly. The solution for cases like PgAioUringContext could be to move the alignas into the struct, but I haven't studied this code closely enough, so I'm leaving it. For int128, there is no straightforward solution, so I'm also leaving that as is.
>
> (The reason for this restriction is that typedefs are supposed to be type aliases that are interchangeable. But if you have two otherwise compatible typedefs with different alignments, this kind of violates the C type system and the compiler has to do some nonstandard magic to handle this (or fail to, see "checking for __int128 alignment bug").)
>
> - You cannot use alignas to underalign a type. So again, int128 cannot be handled by this.
>
> For at least these reasons, I'm leaving pg_attribute_aligned() and some of its more tricky uses in place and unchanged.
> <0001-Add-stdalign.h-to-c.h.patch><0002-C11-alignas-instead-of-unions.patch><0003-Use-C11-alignas-in-pg_atomic_uint64-definitions.patch><0004-C11-alignas-instead-of-unions-extended-alignments.patch>

I can confirm that with this patch, build passed on MacOS 15.6.1, and “make check” passed as well.

0001 is a minimum and straightforward change that enables the use of C11’s alignas and alignof keywords throughout the PostgreSQL source.

0002 simplifies several structures/unions by using alignas, I have a couple of minor comment:

1 - 0002
```
-typedef union PGAlignedBlock
+typedef struct PGAlignedBlock
{
- char data[BLCKSZ];
- double force_align_d;
- int64 force_align_i64;
+ alignas(MAXIMUM_ALIGNOF) char data[BLCKSZ];
} PGAlignedBlock;
```

As we changes PGAlignedBlock from union to structure, I think we can explicitly mention in the commit message something like “PGAlignedBlock has the same alignment and contiguous array data, thus no ABI change”.

2 - 0002
```
- /* page_buffer must be adequately aligned, so use a union */
- union
- {
- char buf[QUEUE_PAGESIZE];
- AsyncQueueEntry align;
- } page_buffer;
+ /* page_buffer must be adequately aligned */
+ alignas(AsyncQueueEntry) char page_buffer[QUEUE_PAGESIZE];
```

To make readers easier to understand the statement, maybe we can explicitly use alignof:

alignas(alignof(AsyncQueueEntry)) char page_buffer[QUEUE_PAGESIZE];

0003 replaces pg_attribute_aligned(8) with alignas(8), no comment.

0004 removes "#ifdef pg_attribute_aligned”, I think that just disables support of very old compilers that we might no longer care about them, which should be okay. For 0004, the same comment as 1.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/