From: Bruce Richardson <bruce.richardson@intel.com>
To: Tyler Retzlaff <roretzla@linux.microsoft.com>
Cc: <dev@dpdk.org>, <techboard@dpdk.org>, <thomas@monjalon.net>,
<david.marchand@redhat.com>, <Honnappa.Nagarahalli@arm.com>,
<mb@smartsharesystems.com>
Subject: Re: C11 atomics adoption blocked
Date: Tue, 8 Aug 2023 19:23:41 +0100 [thread overview]
Message-ID: <ZNKILaydN3RYSwQI@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <20230808175303.GA11006@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
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
next prev parent reply other threads:[~2023-08-08 18:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-08 17:53 Tyler Retzlaff
2023-08-08 18:23 ` Bruce Richardson [this message]
2023-08-08 19:19 ` Tyler Retzlaff
2023-08-08 20:22 ` Morten Brørup
2023-08-08 20:49 ` Tyler Retzlaff
2023-08-09 8:48 ` Morten Brørup
2023-08-14 13:46 ` Thomas Monjalon
2023-08-14 15:13 ` Morten Brørup
2023-08-16 17:25 ` Tyler Retzlaff
2023-08-16 20:30 ` Morten Brørup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZNKILaydN3RYSwQI@bricha3-MOBL.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=mb@smartsharesystems.com \
--cc=roretzla@linux.microsoft.com \
--cc=techboard@dpdk.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).