Fix breakage on arm64_32 platforms

We just avoid the special handling needed for Apple M1.

Fixes #26135

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/26145)

(cherry picked from commit 79c9cbbe1f9c3b8314312b6d8bb25b7138831e04)

diff --git a/crypto/threads_pthread.c b/crypto/threads_pthread.c
index dda6893b013d56f5ced6bf50fd633d5dc70e8030..d344edb047821786cc93d93158656e6197e36439 100644 (file)
--- a/crypto/threads_pthread.c
+++ b/crypto/threads_pthread.c
@@ -72,7 +72,7 @@ typedef struct rcu_cb_item *prcu_cb_item;
 
 # if defined(__GNUC__) && defined(__ATOMIC_ACQUIRE) && !defined(BROKEN_CLANG_ATOMICS) \
     && !defined(USE_ATOMIC_FALLBACKS)
-#  if defined(__APPLE__) && defined(__clang__) && defined(__aarch64__)
+#  if defined(__APPLE__) && defined(__clang__) && defined(__aarch64__) && defined(__LP64__)
 /*
  * For pointers, Apple M1 virtualized cpu seems to have some problem using the
  * ldapr instruction (see https://github.com/openssl/openssl/pull/23974)
@@ -80,9 +80,10 @@ typedef struct rcu_cb_item *prcu_cb_item;
  * atomic loads, which is bad.  So, if
  * 1) We are building on a target that defines __APPLE__ AND
  * 2) We are building on a target using clang (__clang__) AND
- * 3) We are building for an M1 processor (__aarch64__)
- * Then we shold not use __atomic_load_n and instead implement our own
- * function to issue the ldar instruction instead, which procuces the proper
+ * 3) We are building for an M1 processor (__aarch64__) AND
+ * 4) We are building with 64 bit pointers
+ * Then we should not use __atomic_load_n and instead implement our own
+ * function to issue the ldar instruction instead, which produces the proper
  * sequencing guarantees
  */
 static inline void *apple_atomic_load_n_pvoid(void **p,