On Tue, Aug 08, 2023 at 10:53:03AM -0700, Tyler Retzlaff wrote:
> 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).
>
Out of interest, rather than splitting on Windows vs *nix OS for the
atomics, what would it look like if we split behaviour based on C vs C++
use? Would such a thing work?
Also, just wondering about the scope of the changes here. How many header
files are affected where we publicly expose atomics?
Thanks,
/Bruce
