From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Cleaning up historical portability baggage
Date: Fri, 12 Aug 2022 12:56:31 -0400
Message-ID: <166622.1660323391@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+hUKGJdfTFtZXQ8P8CZtyx1k=mHcOD9savHVR2cjSSVp5Uirw@mail.gmail.com>
References: <CA+hUKGJ3LHeP9w5Fgzdr4G8AnEtJ=z=p6hGDEm4qYGEUX5B6fQ@mail.gmail.com>
<CA+Tgmoazusui5EoU_7Z=AgwC5pTAqDndTa7d-owjvQwG3zoRhg@mail.gmail.com>
<CA+hUKGLLJUMDgCzOK5K4NE6PpU87Ka7t7RQsZoZAZ_EKfL5L+A@mail.gmail.com>
<CA+Tgmoaw6VBC9Xzr4vOaC0kc-94jb9nzH8MY38Gqn7=wy=i_3w@mail.gmail.com>
<20220712173352.trdeq66asbv6vf2q@awork3.anarazel.de>
<1662559.1657648462@sss.pgh.pa.us>
<CA+hUKG+MOzmDkr27ceG8+uwgFxbJUUv699V3VP3DCioQigrf7A@mail.gmail.com>
<1249825.1658622186@sss.pgh.pa.us>
<CA+hUKGLryBW4fNYoXzMG9y1e0H-QOTdSiTG46xCr1DNuuPwbeg@mail.gmail.com>
<CA+hUKGJMcwbzRyfTocfxbPBUhERqKE42d-L22jQ+vpB7an-NjQ@mail.gmail.com>
<20220804034343.unm4rdynedbigamv@awork3.anarazel.de>
<3322724.1659586159@sss.pgh.pa.us>
<CA+hUKGJ5ej33AJL19sQph7Z8SFZ6+aUSKxFTS6pvk2Y8J9Tcwg@mail.gmail.com>
<295419.1659918447@sss.pgh.pa.us>
<CA+hUKGK=N8W2uFPdJr07Rs4dgRtbzKaYvCaPQasX3S8=aTO5PQ@mail.gmail.com>
<747620.1660002360@sss.pgh.pa.us>
<CA+hUKG+L_3brvh=8e0BW_VfX9h7MtwgN=nFHP5o7X2oZucY9dg@mail.gmail.com>
<81bb50c! a-d0ea-8cb2-7453-a5058a7b49a8@enterprisedb.com>
<CA+hUKGJdfTFtZXQ8P8CZtyx1k=mHcOD9savHVR2cjSSVp5Uirw@mail.gmail.com>
Continuing the project of removing dead configure tests ...
I see that prairiedog was the only buildfarm animal failing the
HAVE_PPC_LWARX_MUTEX_HINT test, and it seems pretty unlikely that
there are any assemblers remaining in the wild that can't parse that.
(I've confirmed that son-of-prairiedog, the NetBSD 9.3 installation
I'm cranking up on that hardware, is okay with it.)
So, PFA a little patch to remove that test.
It doesn't look like we can remove the adjacent test about "i"
syntax, unfortunately, because the AIX animals still fail that.
regards, tom lane
Attachments:drop-lwarx-hint-test.patch (text/x-diff, 4.3K) downloaddiff --git a/configure b/configureindex cf2c4b85fe..35dcfbb709 100755--- a/configure+++ b/configure@@ -15423,39 +15423,7 @@ $as_echo "#define HAVE_X86_64_POPCNTQ 1" >>confdefs.h
fi
;;
ppc*|powerpc*)
- # On PPC, check if assembler supports LWARX instruction's mutex hint bit- { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether assembler supports lwarx hint bit" >&5-$as_echo_n "checking whether assembler supports lwarx hint bit... " >&6; }-if ${pgac_cv_have_ppc_mutex_hint+:} false; then :- $as_echo_n "(cached) " >&6-else- cat confdefs.h - <<_ACEOF >conftest.$ac_ext-/* end confdefs.h. */--int-main ()-{-int a = 0; int *p = &a; int r;- __asm__ __volatile__ (" lwarx %0,0,%1,1\n" : "=&r"(r) : "r"(p));- ;- return 0;-}-_ACEOF-if ac_fn_c_try_compile "$LINENO"; then :- pgac_cv_have_ppc_mutex_hint=yes-else- pgac_cv_have_ppc_mutex_hint=no-fi-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext-fi-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_have_ppc_mutex_hint" >&5-$as_echo "$pgac_cv_have_ppc_mutex_hint" >&6; }- if test x"$pgac_cv_have_ppc_mutex_hint" = xyes ; then--$as_echo "#define HAVE_PPC_LWARX_MUTEX_HINT 1" >>confdefs.h-- fi- # Check if compiler accepts "i"(x) when __builtin_constant_p(x).+ # On PPC, check if compiler accepts "i"(x) when __builtin_constant_p(x).
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether __builtin_constant_p(x) implies \"i\"(x) acceptance" >&5
$as_echo_n "checking whether __builtin_constant_p(x) implies \"i\"(x) acceptance... " >&6; }
if ${pgac_cv_have_i_constraint__builtin_constant_p+:} false; then :
diff --git a/configure.ac b/configure.acindex b5798bcb0a..a2aa725455 100644--- a/configure.ac+++ b/configure.ac@@ -1687,18 +1687,7 @@ case $host_cpu in
fi
;;
ppc*|powerpc*)
- # On PPC, check if assembler supports LWARX instruction's mutex hint bit- AC_CACHE_CHECK([whether assembler supports lwarx hint bit],- [pgac_cv_have_ppc_mutex_hint],- [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],- [int a = 0; int *p = &a; int r;- __asm__ __volatile__ (" lwarx %0,0,%1,1\n" : "=&r"(r) : "r"(p));])],- [pgac_cv_have_ppc_mutex_hint=yes],- [pgac_cv_have_ppc_mutex_hint=no])])- if test x"$pgac_cv_have_ppc_mutex_hint" = xyes ; then- AC_DEFINE(HAVE_PPC_LWARX_MUTEX_HINT, 1, [Define to 1 if the assembler supports PPC's LWARX mutex hint bit.])- fi- # Check if compiler accepts "i"(x) when __builtin_constant_p(x).+ # On PPC, check if compiler accepts "i"(x) when __builtin_constant_p(x).
AC_CACHE_CHECK([whether __builtin_constant_p(x) implies "i"(x) acceptance],
[pgac_cv_have_i_constraint__builtin_constant_p],
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
diff --git a/src/include/pg_config.h.in b/src/include/pg_config.h.inindex fc5ad5fd65..049c2d204f 100644--- a/src/include/pg_config.h.in+++ b/src/include/pg_config.h.in@@ -349,9 +349,6 @@
/* Define to 1 if you have the `posix_fallocate' function. */
#undef HAVE_POSIX_FALLOCATE
-/* Define to 1 if the assembler supports PPC's LWARX mutex hint bit. */-#undef HAVE_PPC_LWARX_MUTEX_HINT-
/* Define to 1 if you have the `ppoll' function. */
#undef HAVE_PPOLL
diff --git a/src/include/pg_config_manual.h b/src/include/pg_config_manual.hindex 5ee2c46267..ffd385765c 100644--- a/src/include/pg_config_manual.h+++ b/src/include/pg_config_manual.h@@ -236,11 +236,9 @@
* which should be safe in nearly all cases. You might want to override
* this if you are building 32-bit code for a known-recent PPC machine.
*/
-#ifdef HAVE_PPC_LWARX_MUTEX_HINT /* must have assembler support in any case */
#if defined(__ppc64__) || defined(__powerpc64__)
#define USE_PPC_LWARX_MUTEX_HINT
#endif
-#endif
/*
* On PPC machines, decide whether to use LWSYNC instructions in place of
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pmindex cc82668457..243c5fa824 100644--- a/src/tools/msvc/Solution.pm+++ b/src/tools/msvc/Solution.pm@@ -313,7 +313,6 @@ sub GenerateFiles
HAVE_PAM_PAM_APPL_H => undef,
HAVE_POSIX_FADVISE => undef,
HAVE_POSIX_FALLOCATE => undef,
- HAVE_PPC_LWARX_MUTEX_HINT => undef,
HAVE_PPOLL => undef,
HAVE_PS_STRINGS => undef,
HAVE_PTHREAD => undef,
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, thomas.munro@gmail.com, peter.eisentraut@enterprisedb.com, andres@anarazel.de, andrew@dunslane.net, robertmhaas@gmail.com
Subject: Re: Cleaning up historical portability baggage
In-Reply-To: <166622.1660323391@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox