Horton

Re: alignas (C11)

Peter Eisentraut <peter@eisentraut.org>

View thread View on postgr.es
From: Peter Eisentraut <peter@eisentraut.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-01-26T09:34:10Z
Lists: pgsql-hackers 
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.

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