C11 atomics adoption blocked

[Bruce Richardson]

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