They were already using pg_attribute_aligned. This replaces that with
alignas and moves that into the required syntactic position. This
ends up making these three atomics implementations appear a bit more
consistent, but shouldn't change anything otherwise.
Reviewed-by: Chao Li <li.evan.chao@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/
46f05236-d4d4-4b4e-84d4-
faa500f14691%40eisentraut.org
#define PG_HAVE_ATOMIC_U64_SUPPORT
typedef struct pg_atomic_uint64
{
- volatile uint64 value pg_attribute_aligned(8);
+ alignas(8) volatile uint64 value;
} pg_atomic_uint64;
#endif
&& (defined(HAVE_GCC__ATOMIC_INT64_CAS) || defined(HAVE_GCC__SYNC_INT64_CAS))
#define PG_HAVE_ATOMIC_U64_SUPPORT
-
typedef struct pg_atomic_uint64
{
- volatile uint64 value pg_attribute_aligned(8);
+ alignas(8) volatile uint64 value;
} pg_atomic_uint64;
#endif /* defined(HAVE_GCC__ATOMIC_INT64_CAS) || defined(HAVE_GCC__SYNC_INT64_CAS) */
} pg_atomic_uint32;
#define PG_HAVE_ATOMIC_U64_SUPPORT
-typedef struct pg_attribute_aligned(8) pg_atomic_uint64
+typedef struct pg_atomic_uint64
{
- volatile uint64 value;
+ alignas(8) volatile uint64 value;
} pg_atomic_uint64;