Hi folks,
Moving this discussion to the dev mailing list for broader comment.
Unfortunately, we've hit a roadblock with integrating C11 atomics
for DPDK. The main issue is that GNU C++ prior to -std=c++23 explicitly
cannot be integrated with C11 stdatomic.h. Basically, you can't include
the header and you can't use `_Atomic' type specifier to declare atomic
types. This is not a problem with LLVM or MSVC as they both allow
integration with C11 stdatomic.h, but going forward with C11 atomics
would break using DPDK in C++ programs when building with GNU g++.
Essentially you cannot compile the following with g++.
#include <stdatomic.h>
int main(int argc, char *argv[]) { return 0; }
In file included from atomic.cpp:1:
/usr/lib/gcc/x86_64-pc-cygwin/11/include/stdatomic.h:40:9: error:
‘_Atomic’ does not name a type
40 | typedef _Atomic _Bool atomic_bool;
... more errors of same ...
It's also acknowledged as something known and won't fix by GNU g++
maintainers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
Given the timeframe I would like to propose the minimally invasive,
lowest risk solution as follows.
1. Adopt stdatomic.h for all Windows targets, leave all Linux/BSD targets
using GCC builtin C++11 memory model atomics.
2. Introduce a macro that allows _Atomic type specifier to be applied to
function parameter, structure field types and variable declarations.
* The macro would expand empty for Linux/BSD targets.
* The macro would expand to C11 _Atomic keyword for Windows targets.
3. Introduce basic macro that allows __atomic_xxx for normalized use
internal to DPDK.
* The macro would not be defined for Linux/BSD targets.
* The macro would expand __atomic_xxx to corresponding stdatomic.h
atomic_xxx operations for Windows targets.
4. We re-evaluate adoption of C11 atomics and corresponding requirement of
-std=c++23 compliant compiler at the next long term ABI promise release.
Q: Why not define macros that look like the standard and expand those
names to builtins?
A: Because introducing the names is a violation of the C standard, we
can't / shouldn't define atomic_xxx names in the applications namespace
as we are not ``the implementation''.
A: Because the builtins offer a subset of stdatomic.h capability they
can only operate on pointer and integer types. If we presented the
stdatomic.h names there might be some confusion attempting to perform
atomic operations on e.g. _Atomic specified struct would fail but only
on BSD/Linux builds (with the proposed solution).
Please comment asap as we have limited time to define the path forward
within the 23.11 merge window.
Your help is appreciated.
Thanks
