Обсуждение: alignas (C11)
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.
Вложения
Hi, On 2025-11-12 12:39:19 +0100, Peter Eisentraut wrote: > - 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. Maybe I'm confused, but the aligned attribute for PgAioUringContext is on the struct, not the typedef, no? Greetings, Andres Freund
On Thu, Nov 13, 2025 at 12:39 AM Peter Eisentraut <peter@eisentraut.org> wrote: > - 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. While studying atomics recently I noticed BUFFERALIGN, which was originally something like PG_IO_ALIGN_SIZE (see pg_config_manual.h), but is now used as an arbitrary fudge-factor by shared memory allocator-ish things that either know the memory will hold pg_atomic_uint64 or don't know what the memory will hold, since i386 has alignof(uint64_t, double) == 4, but alignof(_Atomic(uint64_t)) == 8, so MAXALIGN is not good enough. I think atomics.h should probably define MAXATOMICALIGN, or something like that. I prototyped that, which led me to pay attention to this __int128 (and typedef) situation, where we went the other way and convinced the compiler to underalign and generate different instructions to fit palloc(). (If palloc were ever used for cross-thread allocation motivating atomic storage, presumably i386 atomics would be an issue there too, but let's ignore that for now...). I guess today we could just do palloc_aligned(sizeof(Int128AggState), alignof(Int128AggState), MCXT_ALLOC_ZERO) for that, and let the compiler worry about the __int128 and its containing struct? I prototyped that and it seemed vaguely plausible, though I can see the argument against it is "what about when the type spreads and someone forgets?", but at first glance it seems to be much more localised than the atomics/shmem problem. IDK. In a very quick hack (so probably missing things) I also seemed to be able to get rid of all our ALIGNOF_ configure probes and just write alignof(int) when I want the alignment of int, move the MAXALIGN derivation into about two lines of c.h, and stuff alignof() inside the right structs as you said...
> On Nov 12, 2025, at 19:39, Peter Eisentraut <peter@eisentraut.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 varietyof places. Also, we can simplify some places where unions are used to encourage alignment, and remove a few workaroundfor lack of alignment attribute support. > > Some detail notes: > > - Technically, compilers are only required to support alignas up to (handwaving over some terminology) the largest alignmentof 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, sothis 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 alignasor __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 PgAioUringContextor the whole int128 business cannot be converted directly. The solution for cases like PgAioUringContextcould be to move the alignas into the struct, but I haven't studied this code closely enough, so I'm leavingit. 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 youhave two otherwise compatible typedefs with different alignments, this kind of violates the C type system and the compilerhas 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 PostgreSQLsource. 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 longercare 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/
On 12.11.25 15:02, Andres Freund wrote: > Hi, > > On 2025-11-12 12:39:19 +0100, Peter Eisentraut wrote: >> - 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. > > Maybe I'm confused, but the aligned attribute for PgAioUringContext is on the > struct, not the typedef, no? Yes, you're right. The immediate problem there is that alignas is not syntactically valid at all at that position.
Hi, On 2025-11-12 16:09:14 +0100, Peter Eisentraut wrote: > On 12.11.25 15:02, Andres Freund wrote: > > Hi, > > > > On 2025-11-12 12:39:19 +0100, Peter Eisentraut wrote: > > > - 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. > > > > Maybe I'm confused, but the aligned attribute for PgAioUringContext is on the > > struct, not the typedef, no? > > Yes, you're right. The immediate problem there is that alignas is not > syntactically valid at all at that position. Argh, why couldn't C copy the C++ rules for this :(. Just moving it to completion_lock would be fine though... Greetings, Andres Freund
On 12.11.25 15:17, Thomas Munro wrote: > In a very quick hack (so probably missing things) I also seemed to be > able to get rid of all our ALIGNOF_ configure probes and just write > alignof(int) when I want the alignment of int, According to my research, using alignof could be quite dangerous for our use, because it does not necessarily match what the ALIGNOF_ probes return. The latter just answer the question, what is the offset if I stick this in a struct as the second field, but that could be larger than the smallest valid alignment for a type. And there are platforms/ABIs where they are actually different. If we didn't have to worry about on-disk compatibility, then using alignof would in theory be better, because if the minimal alignment is actually smaller than the current configure probes compute, then we could save storage. But for the system catalog structs we actually do want the offset-in-struct interpretation, so we're tied to that anyway. (Also, something about AIX here ... :-/) So, I don't know, better be careful with this ... > move the MAXALIGN > derivation into about two lines of c.h, Yes, I had also arrived at that. Just to unify some configure and meson code.