alignas (C11)

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 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/

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.

On 12.11.25 15:27, Chao Li wrote:

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”.

We don't care about ABI changes in major releases.

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];

I don't know. alignas(type) is standard C and seems pretty intuitive to
me. Writing it the long way would be potentially more confusing IMO.

On 12.11.25 12:39, Peter Eisentraut wrote:

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.

This patch set has been committed, it looks like without buildfarm
complaints.

Peter Eisentraut <peter@eisentraut.org> writes:

This patch set has been committed, it looks like without buildfarm
complaints.

Things were fine until test_cplusplusext was added, but now
some older compilers seem to reject this in C++ mode.
For example at [1]https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=chimaera&amp;dt=2026-01-23%2011%3A44%3A01&amp;stg=make-testmodules:

make[1]https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=chimaera&amp;dt=2026-01-23%2011%3A44%3A01&amp;stg=make-testmodules: Entering directory '/home/debian/20-chimaera/buildroot/HEAD/pgsql.build/src/test/modules/test_cplusplusext'
g++ -Wall -Wpointer-arith -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O2 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -I. -I/home/debian/20-chimaera/buildroot/HEAD/pgsql.build/../pgsql/src/test/modules/test_cplusplusext -I../../../../src/include -I/home/debian/20-chimaera/buildroot/HEAD/pgsql.build/../pgsql/src/include -D_GNU_SOURCE -I/usr/include/libxml2 -c -o test_cplusplusext.o /home/debian/20-chimaera/buildroot/HEAD/pgsql.build/../pgsql/src/test/modules/test_cplusplusext/test_cplusplusext.cpp
In file included from /home/debian/20-chimaera/buildroot/HEAD/pgsql.build/../pgsql/src/include/postgres.h:48:0,
from /home/debian/20-chimaera/buildroot/HEAD/pgsql.build/../pgsql/src/test/modules/test_cplusplusext/test_cplusplusext.cpp:18:
/home/debian/20-chimaera/buildroot/HEAD/pgsql.build/../pgsql/src/include/c.h:1126:44: warning: requested alignment 4096 is larger than 128 [-Wattributes]
alignas(PG_IO_ALIGN_SIZE) char data[BLCKSZ];
^
/home/debian/20-chimaera/buildroot/HEAD/pgsql.build/../pgsql/src/include/c.h:1132:49: warning: requested alignment 4096 is larger than 128 [-Wattributes]
alignas(PG_IO_ALIGN_SIZE) char data[XLOG_BLCKSZ];
^

Not sure what to do about that, but I do read it as indicating that we
cannot put any faith in the compiler to honor such large alignment
demands.

A possible short-term(?) workaround is to wrap those two declarations
in "#ifndef __cplusplus", so that C++ code can't declare such
variables.

regards, tom lane

[1]: https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=chimaera&amp;dt=2026-01-23%2011%3A44%3A01&amp;stg=make-testmodules

On 23.01.26 18:33, Tom Lane wrote:
^

/home/debian/20-chimaera/buildroot/HEAD/pgsql.build/../pgsql/src/include/c.h:1132:49: warning: requested alignment 4096 is larger than 128 [-Wattributes]
alignas(PG_IO_ALIGN_SIZE) char data[XLOG_BLCKSZ];
^

Not sure what to do about that, but I do read it as indicating that we
cannot put any faith in the compiler to honor such large alignment
demands.

A possible short-term(?) workaround is to wrap those two declarations
in "#ifndef __cplusplus", so that C++ code can't declare such
variables.

It looks like this was a bug in g++:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70066
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89357

The suggestion there appears to be that it was fixed in gcc 9, but on
the buildfarm it only goes up to 6.

I think we could work around it like this:

#if defined(__cplusplus) && defined(__GNUC__) && __GNUC__ <= 6
#define alignas(a) __attribute__((aligned(a)))
#endif

Peter Eisentraut <peter@eisentraut.org> writes:

On 23.01.26 18:33, Tom Lane wrote:

Not sure what to do about that, but I do read it as indicating that we
cannot put any faith in the compiler to honor such large alignment
demands.

I think we could work around it like this:

#if defined(__cplusplus) && defined(__GNUC__) && __GNUC__ <= 6
#define alignas(a) __attribute__((aligned(a)))
#endif

Hmm, yeah, their bug #70066 shows clearly that the __attribute__
spelling should work. But I think we'd better make the cutoff be
version 9 not version 6, because that same bug is quite clear
about when they fixed it. The lack of complaints from the buildfarm
may just indicate a lack of animals running the intermediate versions.

regards, tom lane

I wrote:

Hmm, yeah, their bug #70066 shows clearly that the __attribute__
spelling should work.

Sorry, copy-and-paste-o; it's

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89357

that has the full statement of the problem and ACK of the fix.

regards, tom lane

On 23.01.26 23:18, Tom Lane wrote:

Peter Eisentraut <peter@eisentraut.org> writes:

On 23.01.26 18:33, Tom Lane wrote:

Not sure what to do about that, but I do read it as indicating that we
cannot put any faith in the compiler to honor such large alignment
demands.

I think we could work around it like this:

#if defined(__cplusplus) && defined(__GNUC__) && __GNUC__ <= 6
#define alignas(a) __attribute__((aligned(a)))
#endif

Hmm, yeah, their bug #70066 shows clearly that the __attribute__
spelling should work. But I think we'd better make the cutoff be
version 9 not version 6, because that same bug is quite clear
about when they fixed it. The lack of complaints from the buildfarm
may just indicate a lack of animals running the intermediate versions.

Ok, done that way.

Peter Eisentraut <peter@eisentraut.org> writes:

On 23.01.26 23:18, Tom Lane wrote:

Hmm, yeah, their bug #70066 shows clearly that the __attribute__
spelling should work. But I think we'd better make the cutoff be
version 9 not version 6, because that same bug is quite clear
about when they fixed it. The lack of complaints from the buildfarm
may just indicate a lack of animals running the intermediate versions.

Ok, done that way.

Sigh ... that did not work. Various BF animals are now blowing up in
src/backend/jit/llvm because this macro definition breaks some usages
of alignas() in LLVM header files.

Maybe we could #define alignas this way for the two exposed usages
and then #undef afterwards?

regards, tom lane

On 25.01.26 18:14, Tom Lane wrote:

Peter Eisentraut <peter@eisentraut.org> writes:

On 23.01.26 23:18, Tom Lane wrote:

Hmm, yeah, their bug #70066 shows clearly that the __attribute__
spelling should work. But I think we'd better make the cutoff be
version 9 not version 6, because that same bug is quite clear
about when they fixed it. The lack of complaints from the buildfarm
may just indicate a lack of animals running the intermediate versions.

Ok, done that way.

Sigh ... that did not work. Various BF animals are now blowing up in
src/backend/jit/llvm because this macro definition breaks some usages
of alignas() in LLVM header files.

Maybe we could #define alignas this way for the two exposed usages
and then #undef afterwards?

Well, in C11, alignas is itself a macro (defined to _Alignas). I
suppose not in C++ though. That seems too tricky, though. I went with
your original proposal of disabling the affected typedefs on the
affected platform. That seems safest. These types aren't likely to be
used in extensions anyway, so this should have minimal practical impact.

Peter Eisentraut <peter@eisentraut.org> writes:

Well, in C11, alignas is itself a macro (defined to _Alignas). I
suppose not in C++ though. That seems too tricky, though. I went with
your original proposal of disabling the affected typedefs on the
affected platform. That seems safest. These types aren't likely to be
used in extensions anyway, so this should have minimal practical impact.

I suspected that we'd have to supply the types as abstract structs
per my earlier suggestion, and just found a good reason why:
"headerscheck --cplusplus" is failing for me on RHEL8, because it
tries to parse all headers under C++. This is blocking progress on
another patch, so I went ahead and committed the addition.

regards, tom lane