[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