Horton

Thread

Commits

  1. Further fix extended alignment for older g++.

  2. Disable extended alignment uses on older g++

  3. Work around buggy alignas in older g++

  4. Use C11 alignas in pg_atomic_uint64 definitions

  5. C11 alignas instead of unions -- extended alignments

  6. C11 alignas instead of unions

  7. Add <stdalign.h> to c.h

  1. alignas (C11)

    Peter Eisentraut <peter@eisentraut.org> — 2025-11-12T11:39:19Z

    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.

  2. Re: alignas (C11)

    Andres Freund <andres@anarazel.de> — 2025-11-12T14:02:42Z

    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

  3. Re: alignas (C11)

    Thomas Munro <thomas.munro@gmail.com> — 2025-11-12T14:17:09Z

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

  4. Re: alignas (C11)

    Chao Li <li.evan.chao@gmail.com> — 2025-11-12T14:27:22Z

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

  5. Re: alignas (C11)

    Peter Eisentraut <peter@eisentraut.org> — 2025-11-12T15:09:14Z

    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.

  6. Re: alignas (C11)

    Andres Freund <andres@anarazel.de> — 2025-11-12T15:17:19Z

    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

  7. Re: alignas (C11)

    Peter Eisentraut <peter@eisentraut.org> — 2025-11-12T15:33:08Z

    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.

  8. Re: alignas (C11)

    Peter Eisentraut <peter@eisentraut.org> — 2025-11-18T13:35:59Z

    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.

  9. Re: alignas (C11)

    Peter Eisentraut <peter@eisentraut.org> — 2025-12-01T07:03:49Z

    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.

  10. Re: alignas (C11)

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-23T17:33:26Z

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

make[1]: 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&dt=2026-01-23%2011%3A44%3A01&stg=make-testmodules

  11. Re: alignas (C11)

    Peter Eisentraut <peter@eisentraut.org> — 2026-01-23T22:00:43Z

    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

  12. Re: alignas (C11)

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-23T22:18:44Z

    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

  13. Re: alignas (C11)

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-23T22:20:20Z

    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

  14. Re: alignas (C11)

    Peter Eisentraut <peter@eisentraut.org> — 2026-01-25T10:34:38Z

    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.

  15. Re: alignas (C11)

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-25T17:14:03Z

    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

  16. Re: alignas (C11)

    Peter Eisentraut <peter@eisentraut.org> — 2026-01-26T09:34:10Z

    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.

  17. Re: alignas (C11)

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-29T21:19:27Z

    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