From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 095CEA04DB; Thu, 15 Oct 2020 09:13:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4BD251DCA8; Thu, 15 Oct 2020 09:13:13 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by dpdk.org (Postfix) with ESMTP id 9D3B41D936 for ; Thu, 15 Oct 2020 09:13:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1602745990; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SYa4yzlKjRmUH0DizvCCV1TO2RlbjxYLFv0h6WB2890=; b=gb+Q/L6XPubYA/73j2T76mgC1n6aBo/1DhRN+Z4mBBmaKBprrckzgb/U9S/py+1IhYvI+b IVvWVdSsZwNXiVpJgnuY7rvDciVooTShZgWsqBjjZpbai8Gt1C2bsY7UsIm1FUz6VGGwxK /EUwt8EA0gJZYK5bkMov7pCsZjMs4ZM= Received: from mail-vs1-f71.google.com (mail-vs1-f71.google.com [209.85.217.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-378-0JBn5Eb-MYCtc2T4HMowgA-1; Thu, 15 Oct 2020 03:13:08 -0400 X-MC-Unique: 0JBn5Eb-MYCtc2T4HMowgA-1 Received: by mail-vs1-f71.google.com with SMTP id s130so684976vsc.13 for ; Thu, 15 Oct 2020 00:13:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SYa4yzlKjRmUH0DizvCCV1TO2RlbjxYLFv0h6WB2890=; b=aYKDKFFx1sMHPD7Hh6bImHBb3vxNNyGwydvfSDdXI/oXY+ESSWdP9jhd+Nx4+2TXxz HOLUivbLGq3YVNCCnrwywkPZ9x+6KpDAUzy5hAEWdeG2SMsm+pumamcU1TuCLu/Vmrb9 XhKv19qErW4STmx4EwAzj0yRS7YZB4UFyMBnaH09z3FWOqUc1GFCKFrZGec96zifG/qn ceZ66RxBlz3tk2FSZjx3tACANiygT0wJdU8LR4+FiJnaLpzqtSak0rx5XlifyVnoV1i+ 08XZcByxfwE6t4rp9ic4d24YfjRFibdUo1YgHFZ4g/DnhsUeYAS44QSkuH+ROxylExbo Eb0Q== X-Gm-Message-State: AOAM530BHvLXXWrYvDZ8oDCzBnOAQEDCGAyKaD7iOMeHEsvJ0BO7mwze NPw8V56x+isbmCL6i5NZtXgSSycW1DeSFyBouGyv9U8ryWhiL4rl/WSLjwx59NuhiZszLCz3Q9v bOOKYJaxpecSpG7vshhM= X-Received: by 2002:a67:e2d5:: with SMTP id i21mr1821050vsm.18.1602745987798; Thu, 15 Oct 2020 00:13:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxkJeSwAZv3vLFj3ZzwoQ4wSIR4bGADjFS1dxjqEdCYIatBoSaAtXx3y+Kl7K0cpe8AsB+Dd1qrFEis5myl18k= X-Received: by 2002:a67:e2d5:: with SMTP id i21mr1821040vsm.18.1602745987518; Thu, 15 Oct 2020 00:13:07 -0700 (PDT) MIME-Version: 1.0 References: <20201014061909.9957-1-elibr@nvidia.com> <1634944.yJlA45dGKM@thomas> In-Reply-To: <1634944.yJlA45dGKM@thomas> From: David Marchand Date: Thu, 15 Oct 2020 09:12:56 +0200 Message-ID: To: Thomas Monjalon , Eli Britstein Cc: dev Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH] eal: fix build with conflicting libc variable memory_order X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Oct 15, 2020 at 1:16 AM Thomas Monjalon wrote: > > 14/10/2020 08:19, Eli Britstein: > > The cited commit introduced functions with 'int memory_order' argument. > > The C11 standard section 7.17.1.4 defines 'memory_order' as the > > "enumerated type whose enumerators identify memory ordering constraints". > > Applications that use the standard enum (includes stdatomic.h), will > > fail compilation with: Simply including stdatomic.h does not trigger the problem. Can you rework this commitlog with below info? > > error: declaration of 'memory_order' shadows a global declaration > > [-Werror=shadow] > > rte_atomic_thread_fence(int memory_order) > > Fix it by changing the argument name 'memory_order' to 'memorder'. > > Not clear why it builds fine with most compilers, I can reproduce in two cases: - with a gcc that provides a stdatomic.h header + passing -Wsystem-headers in the CFLAGS, - with a compiler that does not provide stdatomic.h and you redefine memory_order in your code (like OVS does), > but the fix does not hurt. Otherwise, yes, lgtm. > > Fixes: 672a15056380 ("eal: add wrapper for C11 atomic thread fence") > > A blank line should be inserted here. > > > Signed-off-by: Eli Britstein > > Acked-by: Thomas Monjalon Acked-by: David Marchand -- David Marchand