> On Nov 12, 2025, at 19:39, Peter Eisentraut <[email protected]> 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/
