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)

diff --git a/crypto/threads_pthread.c b/crypto/threads_pthread.c
index 7d25b241e19f36b8fb048813105beb0c081df8e6..bfd04fa4f153b7d790578fdef3d9af3a9fed04fa 100644 (file)
--- a/crypto/threads_pthread.c
+++ b/crypto/threads_pthread.c
@@ -94,7 +94,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)
@@ -102,7 +102,8 @@ 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__)
+ * 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