[PATCH] eal: fix C++ builds when stdatomics is set

[PATCH] eal: fix C++ builds when stdatomics is set

[Bruce Richardson]

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: stable@dpdk.org

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 lib/eal/include/rte_stdatomic.h | 75 +++++++++++++++++++++++++++++++++
 1 file changed, 75 insertions(+)

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

Re: [PATCH] eal: fix C++ builds when stdatomics is set

[David Marchand]

On Thu, 24 Sept 2026 at 16:13, Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> 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: stable@dpdk.org
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>

Probably worth squashing this in (I tested in GHA):

$ git diff
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"


Compilation passes fine in my env and GHA.


-- 
David Marchand

Re: [PATCH] eal: fix C++ builds when stdatomics is set

[Bruce Richardson]

On Fri, Sep 25, 2026 at 12:13:41PM +0200, David Marchand wrote:
> On Thu, 24 Sept 2026 at 16:13, Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > 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: stable@dpdk.org
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> 
> Probably worth squashing this in (I tested in GHA):
> 
> $ git diff
> 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"
> 
> 
> Compilation passes fine in my env and GHA.
> 
Sure. Shall I do a respin to include that?

/Bruce

Re: [PATCH] eal: fix C++ builds when stdatomics is set

[David Marchand]

On Fri, 25 Sept 2026 at 12:54, Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Fri, Sep 25, 2026 at 12:13:41PM +0200, David Marchand wrote:
> > On Thu, 24 Sept 2026 at 16:13, Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > 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: stable@dpdk.org
> > >
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> >
> > Probably worth squashing this in (I tested in GHA):
> >
> > $ git diff
> > 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"
> >
> >
> > Compilation passes fine in my env and GHA.
> >
> Sure. Shall I do a respin to include that?

Yes please, not worth a separate commit.


-- 
David Marchand

[PATCH v2] eal: fix C++ builds when stdatomics is set

[Bruce Richardson]

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: stable@dpdk.org

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 .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

Re: [PATCH v2] eal: fix C++ builds when stdatomics is set

[Thomas Monjalon]

25/09/2026 14:49, Bruce Richardson:
> 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: stable@dpdk.org
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>

Applied, thanks.