On 2024-04-30 01:14, Tyler Retzlaff wrote:
On Mon, Apr 29, 2024 at 06:21:13AM +0000, bugzi...@dpdk.org wrote:
https://bugs.dpdk.org/show_bug.cgi?id=1425
Bug ID: 1425
Summary: enable_stdatomic=true breaks C++ on GCC 11 and
earlier
Product: DPDK
Version: 23.11
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: core
Assignee: dev@dpdk.org
Reporter: mattias.ronnb...@ericsson.com
Target Milestone: ---
On GCC 11 and earlier, configuring enable_stdatomic=true prevents the use of
all DPDK header files that directly or indirectly include <rte_stdatomic.h>
from a C++ translation unit (e.g., app).
<rte_stdatomic.h> includes <stdatomic.h>, which in turn is not necessarily
C++-compatible.
This is known but to add some information.
Is it also documented?
C++ and enable_stdatomic=true for llvm and gcc are not currently
supported. the combination will remain unsupported for C++ compilers
that do not support -std=c++23 which is the first C++ standard that
requires interoperability with C11 stdatomic.h >
When enable_stdatomic=true there are bugs/incorrect usages of atomic
qualifier in casts that (even when using C++23) cause compilation
failure. These are a fixable but are low priority without -std=c++23.
Finally, the legacy atomics remain unconverted to stdatomic. This will
cause enable_stdatomic=true not to build when using llvm (but not gcc)
because llvm strictly enforces qualification when using atomic generics.
OK, I see. It'll be a while until enable_stdatomic is usable outside
Windows then, for generic builds.
Am I right if I say that C++23-capable compilers/run-times are supposed
to have a <stdatomic.h> which interoperates with C++ even in C++11-mode?
Or need the application be compiled as C++23.
--
You are receiving this mail because:
You are the assignee for the bug.
