[PATCH v2] eal: fix C++ builds when stdatomics is set
Thomas Monjalon
thomas at monjalon.net
Tue Sep 29 09:23:58 CEST 2026
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 at dpdk.org
>
> Signed-off-by: Bruce Richardson <bruce.richardson at intel.com>
Applied, thanks.
More information about the stable
mailing list