When the DPDK build is configured to use stdatomics rather than compiler
builtin atomics, the C++ chkincs builds were failing
In file included from buildtools/chkincs/staging/generic/rte_atomic.h:18,
from
/home/morten/upstreaming/dpdk-stack-std/lib/eal/x86/include/rte_atomic.h:12,
from buildtools/chkincs/chkincs-cpp.p/rte_atomic.cpp:1:
buildtools/chkincs/staging/rte_stdatomic.h:30:9: error: ‘memory_order’ does not
name a type
30 | typedef memory_order rte_memory_order;
| ^~~~~~~~~~~~
The cause is differences in atomics in C (C11) and C++ (e.g. C++17 as
supported by current GCC). As explained by AI analysis:
_Atomic(T) is a C11 feature. In C++ mode, GCC 15 does not support it
as a type specifier, and <stdatomic.h> in C++17 doesn't expose
memory_order in the global namespace (that's only in C++23). DPDK
headers also use _Atomic in anonymous unions and under extern "C",
which are incompatible with C++'s std::atomic<T> mapping.
To fix this in a resilient manner we need to go from two blocks in
rte_atomic.h to three. We have the existing non-standard/builtin
atomics path, but the standard atomic path now needs to be split into C
compatible and C++ compatible blocks. This fixes the build issues with
C++ while keeping existing C builds unchanged.
Bugzilla ID: 1985
Fixes: 5c381a3587d1 ("eal: provide stdatomic API")
Cc: [email protected]
Signed-off-by: Bruce Richardson <[email protected]>
---
.ci/linux-build.sh | 11 +++--
lib/eal/include/rte_stdatomic.h | 75 +++++++++++++++++++++++++++++++++
2 files changed, 80 insertions(+), 6 deletions(-)
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index e0b914a142..b09d72dd87 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -111,13 +111,12 @@ OPTS="$OPTS -Dplatform=generic"
OPTS="$OPTS -Ddefault_library=$DEF_LIB"
if [ "$STDATOMIC" = "true" ]; then
OPTS="$OPTS -Denable_stdatomic=true"
+fi
+OPTS="$OPTS -Dcheck_includes=true"
+if [ "${CC%%clang}" != "$CC" ]; then
+ export CXX=clang++
else
- OPTS="$OPTS -Dcheck_includes=true"
- if [ "${CC%%clang}" != "$CC" ]; then
- export CXX=clang++
- else
- export CXX=g++
- fi
+ export CXX=g++
fi
if [ "$MINI" = "true" ]; then
OPTS="$OPTS -Denable_drivers=net/null"
diff --git a/lib/eal/include/rte_stdatomic.h b/lib/eal/include/rte_stdatomic.h
index 7258b393f1..d31eb4bfab 100644
--- a/lib/eal/include/rte_stdatomic.h
+++ b/lib/eal/include/rte_stdatomic.h
@@ -8,6 +8,8 @@
#include <assert.h>
#ifdef RTE_ENABLE_STDATOMIC
+
+#ifndef __cplusplus
#ifndef _MSC_VER
#ifdef __STDC_NO_ATOMICS__
#error enable_stdatomic=true but atomics not supported by toolchain
@@ -114,6 +116,79 @@ static_assert(rte_memory_order_seq_cst == __ATOMIC_SEQ_CST,
#define __rte_atomic_thread_fence(memorder) \
atomic_thread_fence(memorder)
+#else /* __cplusplus */
+
+/* C++ cannot use the C11 _Atomic member layout that DPDK public headers
+ * rely on, so keep the builtin-based implementation for C++ and continue
+ * to expose the existing rte_atomic_* API surface.
+ */
+#define RTE_ATOMIC(type) type
+
+#define __rte_atomic
+
+/* The memory order is an integer type in GCC built-ins,
+ * not an enumerated type like in C11.
+ */
+typedef int rte_memory_order;
+
+#define rte_memory_order_relaxed __ATOMIC_RELAXED
+#define rte_memory_order_consume __ATOMIC_CONSUME
+#define rte_memory_order_acquire __ATOMIC_ACQUIRE
+#define rte_memory_order_release __ATOMIC_RELEASE
+#define rte_memory_order_acq_rel __ATOMIC_ACQ_REL
+#define rte_memory_order_seq_cst __ATOMIC_SEQ_CST
+
+#define rte_atomic_load_explicit(ptr, memorder) \
+ __atomic_load_n(ptr, memorder)
+
+#define rte_atomic_store_explicit(ptr, val, memorder) \
+ __atomic_store_n(ptr, val, memorder)
+
+#define rte_atomic_exchange_explicit(ptr, val, memorder) \
+ __atomic_exchange_n(ptr, val, memorder)
+
+#define rte_atomic_compare_exchange_strong_explicit(ptr, expected, desired, \
+ succ_memorder, fail_memorder) \
+ __atomic_compare_exchange_n(ptr, expected, desired, 0, \
+ succ_memorder, fail_memorder)
+
+#define rte_atomic_compare_exchange_weak_explicit(ptr, expected, desired, \
+ succ_memorder, fail_memorder) \
+ __atomic_compare_exchange_n(ptr, expected, desired, 1, \
+ succ_memorder, fail_memorder)
+
+#define rte_atomic_fetch_add_explicit(ptr, val, memorder) \
+ __atomic_fetch_add(ptr, val, memorder)
+
+#define rte_atomic_fetch_sub_explicit(ptr, val, memorder) \
+ __atomic_fetch_sub(ptr, val, memorder)
+
+#define rte_atomic_fetch_and_explicit(ptr, val, memorder) \
+ __atomic_fetch_and(ptr, val, memorder)
+
+#define rte_atomic_fetch_xor_explicit(ptr, val, memorder) \
+ __atomic_fetch_xor(ptr, val, memorder)
+
+#define rte_atomic_fetch_or_explicit(ptr, val, memorder) \
+ __atomic_fetch_or(ptr, val, memorder)
+
+#define rte_atomic_fetch_nand_explicit(ptr, val, memorder) \
+ __atomic_fetch_nand(ptr, val, memorder)
+
+#define rte_atomic_flag_test_and_set_explicit(ptr, memorder) \
+ __atomic_test_and_set(ptr, memorder)
+
+#define rte_atomic_flag_clear_explicit(ptr, memorder) \
+ __atomic_clear(ptr, memorder)
+
+/* We provide internal macro here to allow conditional expansion
+ * in the body of the per-arch rte_atomic_thread_fence inline functions.
+ */
+#define __rte_atomic_thread_fence(memorder) \
+ __atomic_thread_fence(memorder)
+
+#endif /* __cplusplus */
+
#else /* !RTE_ENABLE_STDATOMIC */
#define RTE_ATOMIC(type) type
--
2.53.0
