Various code assumed this was true already, and usually it is.
However, it emerges that in a "universal" (multi-architecture)
macOS build, configure will define USE_AVX2_WITH_RUNTIME_CHECK
if the build host is x86_64, and then the arm64 half of the
build fails.
Ideally we'd get pg_config.h to define this symbol conditionally
depending on defined(__x86_64__), but I don't see any way to
persuade Autoconf to do that. Instead, clean up the mess by
#undef'ing it again in c.h for not-x86_64 builds.
For consistency I made c.h also #undef the USE_AVX512... symbols.
Those are not actively broken, but it seems only happenstance
that configure's tests for them fail in a universal build.
Down the road we may have occasion to add more #undef's here.
This problem is new in v19, so no need for back-patch.
Reported-by: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>
Reported-by: Tobias Bussmann <t.bussmann@gmx.net>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/
15574903-87C9-478A-B2D7-
CC8F4C275DBB@gmx.net
#if (defined(__x86_64__) || defined(_M_AMD64))
#define USE_SSE2
+#else /* ! x86_64 */
+
+/*
+ * In "universal" macOS builds, it's possible for AVX-related symbols to
+ * get defined if the build host is x86_64, but we mustn't try to build
+ * that code when cross-compiling to aarch64.
+ */
+#undef USE_AVX2_WITH_RUNTIME_CHECK
+#undef USE_AVX512_CRC32C_WITH_RUNTIME_CHECK
+#undef USE_AVX512_POPCNT_WITH_RUNTIME_CHECK
+
/*
* We use the Neon instructions if the compiler provides access to them (as
* indicated by __ARM_NEON) and we are on aarch64. While Neon support is
* could not realistically use it there without a run-time check, which seems
* not worth the trouble for now.
*/
-#elif defined(__aarch64__) && defined(__ARM_NEON)
+#if defined(__aarch64__) && defined(__ARM_NEON)
#define USE_NEON
#endif
+#endif /* x86_64 */
/* ----------------------------------------------------------------
* Section 9: system-specific hacks