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 27762428C4; Mon, 3 Apr 2023 23:32:56 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B023340ED7; Mon, 3 Apr 2023 23:32:55 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 93B134067E for ; Mon, 3 Apr 2023 23:32:54 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 45C8015390 for ; Mon, 3 Apr 2023 23:32:54 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 44A0514D74; Mon, 3 Apr 2023 23:32:54 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=ALL_TRUSTED, AWL, NICE_REPLY_A autolearn=disabled version=3.4.6 X-Spam-Score: -2.1 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 28B0615504; Mon, 3 Apr 2023 23:32:51 +0200 (CEST) Message-ID: <4c7b5e51-51bd-fc88-b0b2-a952332d9f47@lysator.liu.se> Date: Mon, 3 Apr 2023 23:32:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH v2] eal: introduce atomics abstraction Content-Language: en-US To: Tyler Retzlaff , Bruce Richardson Cc: dev@dpdk.org, david.marchand@redhat.com, thomas@monjalon.net, mb@smartsharesystems.com, Honnappa.Nagarahalli@arm.com References: <1673558785-24992-1-git-send-email-roretzla@linux.microsoft.com> <1675892618-31755-1-git-send-email-roretzla@linux.microsoft.com> <1675892618-31755-2-git-send-email-roretzla@linux.microsoft.com> <20230209173804.GB21854@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= In-Reply-To: <20230209173804.GB21854@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP 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 On 2023-02-09 18:38, Tyler Retzlaff wrote: > On Thu, Feb 09, 2023 at 09:04:16AM +0000, Bruce Richardson wrote: >> On Wed, Feb 08, 2023 at 01:43:38PM -0800, Tyler Retzlaff wrote: >>> Introduce atomics abstraction that permits optional use of standard C11 >>> atomics when meson is provided the new enable_stdatomics=true option. >>> >>> Signed-off-by: Tyler Retzlaff >>> --- >>> config/meson.build | 11 ++++ >>> lib/eal/arm/include/rte_atomic_32.h | 6 ++- >>> lib/eal/arm/include/rte_atomic_64.h | 6 ++- >>> lib/eal/include/generic/rte_atomic.h | 96 +++++++++++++++++++++++++++++++++- >>> lib/eal/loongarch/include/rte_atomic.h | 6 ++- >>> lib/eal/ppc/include/rte_atomic.h | 6 ++- >>> lib/eal/riscv/include/rte_atomic.h | 6 ++- >>> lib/eal/x86/include/rte_atomic.h | 8 ++- >>> meson_options.txt | 2 + >>> 9 files changed, 139 insertions(+), 8 deletions(-) >>> >>> diff --git a/config/meson.build b/config/meson.build >>> index 26f3168..25dd628 100644 >>> --- a/config/meson.build >>> +++ b/config/meson.build >>> @@ -255,6 +255,17 @@ endif >>> # add -include rte_config to cflags >>> add_project_arguments('-include', 'rte_config.h', language: 'c') >>> >>> +stdc_atomics_enabled = get_option('enable_stdatomics') >>> +dpdk_conf.set('RTE_STDC_ATOMICS', stdc_atomics_enabled) >>> + >>> +if stdc_atomics_enabled >>> +if cc.get_id() == 'gcc' or cc.get_id() == 'clang' >>> + add_project_arguments('-std=gnu11', language: 'c') >> >> Is there a reason for using gnu11 on gcc and clang, rather than limiting >> ourselves to proper c11 support? > > there is code using posix extensions, there are two ways to use them > without emitting warnings. > > 1. -std=gnu11 (to get C11 with GNU extensions) > > -- or -- > > 2. -std=c11 and then in the source files consuming the C11 GNU > extensions do some dance with various GNUC macros before including > various stdxxx.h headers to enable the extensions for the translation > unit. > > i vaguely recall that if you try to do a test build with -std=c11 over > the whole tree with meson --werror it will highlight the exact code i'm > talking about. > > selfishly i'd be happy to see (2) done and potentially eliminate the use > of the extensions, but i didn't want to be disruptive as a part of this > change. > Some of the GNU extensions are useful, and have no equivalent in C11. Statement expressions is one example that comes to mind. I think you can get such code through GCC even with -std=c11, but not if combined with -pedantic.