From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 076C74300E; Tue, 8 Aug 2023 19:53:06 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9252C41148; Tue, 8 Aug 2023 19:53:05 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 7ED3C410E6; Tue, 8 Aug 2023 19:53:04 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id BEE0A20FC050; Tue, 8 Aug 2023 10:53:03 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com BEE0A20FC050 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1691517183; bh=NcsoNoy9J1PZFQJ7+WFlWxmlf3+ufjDToufjMaD0oSQ=; h=Date:From:To:Cc:Subject:From; b=pXwmGNU5fRAsSv2Tlhc0+NaAC4Y8yV/VJfEGs453IRrjGxLPtSdf01OZ37EimuMpd Erh01quU4iQics3LvhzyWgoVt558cSPXXHSU6BFuJRc6MqoXjIMcIGKrNwWCFU02zw P1NacNYJVCOtQj5ZuX+csvYSgAKc1WaLjyBsxlUc= Date: Tue, 8 Aug 2023 10:53:03 -0700 From: Tyler Retzlaff To: dev@dpdk.org, techboard@dpdk.org Cc: thomas@monjalon.net, david.marchand@redhat.com, Honnappa.Nagarahalli@arm.com, mb@smartsharesystems.com Subject: C11 atomics adoption blocked Message-ID: <20230808175303.GA11006@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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 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