Thanks Hikki, for going through the changes.
> +/* Commenting for XLC > + * "IBM XL C/C++ for AIX, V12.1" miscompiles, for 32-bit, some inline > + * expansions of ginCompareItemPointers() "long long" arithmetic. To take > + * advantage of inlining, build a 64-bit PostgreSQL. > +#if defined(__ILP32__) && defined(__IBMC__) > +#define PG_FORCE_DISABLE_INLINE > +#endif > + */ I can remove these unwanted comments. I have to analyze the changes for the rest of your comment and will get back to you. Warm regards, Sriram. From: Heikki Linnakangas <hlinn...@gmail.com> Date: Wednesday, 19 June 2024 at 8:45 PM To: Srirama Kucherlapati <sriram...@in.ibm.com>, Laurenz Albe <laurenz.a...@cybertec.at>, Bruce Momjian <br...@momjian.us>, Heikki Linnakangas <hlinn...@iki.fi> Cc: Peter Eisentraut <pe...@eisentraut.org>, Alvaro Herrera <alvhe...@alvh.no-ip.org>, pgsql-hack...@postgresql.org <pgsql-hack...@postgresql.org>, Noah Misch <n...@leadboat.com>, Michael Paquier <mich...@paquier.xyz>, Andres Freund <and...@anarazel.de>, Tom Lane <t...@sss.pgh.pa.us>, Thomas Munro <thomas.mu...@gmail.com>, tvk1...@gmail.com <tvk1...@gmail.com>, postgres-ibm-...@wwpdl.vnet.ibm.com <postgres-ibm-...@wwpdl.vnet.ibm.com> Subject: [EXTERNAL] Re: AIX support On 19/06/2024 17:55, Srirama Kucherlapati wrote: > +/* Commenting for XLC > + * "IBM XL C/C++ for AIX, V12.1" miscompiles, for 32-bit, some inline > + * expansions of ginCompareItemPointers() "long long" arithmetic. To take > + * advantage of inlining, build a 64-bit PostgreSQL. > +#if defined(__ILP32__) && defined(__IBMC__) > +#define PG_FORCE_DISABLE_INLINE > +#endif > + */ This seems irrelevant. > + * Ordinarily, we'd code the branches here using GNU-style local symbols, > that > + * is "1f" referencing "1:" and so on. But some people run gcc on AIX with > + * IBM's assembler as backend, and IBM's assembler doesn't do local symbols. > + * So hand-code the branch offsets; fortunately, all PPC instructions are > + * exactly 4 bytes each, so it's not too hard to count. Could you use GCC assembler to avoid this? > @@ -662,6 +666,21 @@ tas(volatile slock_t *lock) > > #if !defined(HAS_TEST_AND_SET) /* We didn't trigger above, let's try > here */ > > +#if defined(_AIX) /* AIX */ > +/* > + * AIX (POWER) > + */ > +#define HAS_TEST_AND_SET > + > +#include <sys/atomic_op.h> > + > +typedef int slock_t; > + > +#define TAS(lock) _check_lock((slock_t *) (lock), 0, 1) > +#define S_UNLOCK(lock) _clear_lock((slock_t *) (lock), 0) > +#endif /* _AIX */ > + > + > /* These are in sunstudio_(sparc|x86).s */ > > #if defined(__SUNPRO_C) && (defined(__i386) || defined(__x86_64__) || > defined(__sparc__) || defined(__sparc)) What CPI/compiler/OS configuration is this for, exactly? Could we rely on GCC-provided __sync_lock_test_and_set() builtin function instead? > +# Allow platforms with buggy compilers to force restrict to not be > +# used by setting $FORCE_DISABLE_RESTRICT=yes in the relevant > +# template. Surely we don't need that anymore? Or is the compiler still buggy? Do you still care about 32-bit binaries on AIX? If not, let's make that the default in configure or a check for it, and remove the instructions on building 32-bit binaries from the docs. Please try hard to remove any changes from the diff that are not absolutely necessary. - Heikki
