From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by dpdk.org (Postfix) with ESMTP id 766C45B20 for ; Mon, 3 Sep 2018 11:29:28 +0200 (CEST) Received: by mail-wr1-f67.google.com with SMTP id v16-v6so17099129wro.11 for ; Mon, 03 Sep 2018 02:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=4iKwLMgf8OaKTRWFAMYacDWCYJ0n+B0vXeh+AC8z0PQ=; b=Y9viKK1HPfhbL7Pjyy4kh4V8qf1/9/IsiZKHKRdaEeXiMjMicetfXGj89skUE6tY2h gN7zgxWNyHjZ1Jlv9nPsLrmNJERp2tZnxMhKVTQq1nJACw/dUKk9Nrbg3FeWd2daFuTB 2IM2ukvDWmja3SQMaymopCk22B/+ITEfNruUrJlILIA3Qqbpqqx3BUotzOdTS2a+CXnO gUdIWQBCeBFONPRchyf8ArLzI98g37ebW5p2QuzxMULPUsGwW/001d8xkw92Rt5zuSe3 AUbfpsfdS1pfgxzHMd/1kg1GZ0BGCY9YPxuv7o94QX4RW3HAhZ73rZG9VRpSe9ZmrpvT g1mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=4iKwLMgf8OaKTRWFAMYacDWCYJ0n+B0vXeh+AC8z0PQ=; b=fLhGgyQnRXBXB5EKgpAXuafRKbdtABdgnXY9hbjDmELKixCASaBkUMgnzH8m1L6B7j n2b2VBikePOb4wD6gg3Ht4HplZOz9QSjJ4f9mX2SuNa3O2/PO7/XB//BZtumAooReHCd mFBRiqvpNMdCj+ONKPtfdH8vd38h/nGhB2L/ssq4yLwZofuedKJ5+2Irph5KcVt36v5m G85Y/IKQ4phdz57cccLI/TPnK6TFTP8s33A1MDB20L0nffD88AVxpPMl93YTl5mNOZ8n 7d+3rJ4z3v4Ym16sRGm7ZYyxMMIKFd6UvEt62vtzeqRkPhuzfbKZc3aOTE5t+rmM3mJo LPJg== X-Gm-Message-State: APzg51AXIdHZmt9poWLi/XaC08IHzVIIIUXRUn/tq7UKTvhdG8PCA9Pc k4sNgMaITo5hlRkzs2XXyFLagg== X-Google-Smtp-Source: ANB0VdZSEoFAD0NlZRGbKUkUzhc/x4gB+wnBX88G2oD9/0sGheZVVvKvT6qBV52HeHoBNF9g1CDeQg== X-Received: by 2002:a5d:4d82:: with SMTP id b2-v6mr17802636wru.80.1535966968242; Mon, 03 Sep 2018 02:29:28 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id 200-v6sm21411626wmv.6.2018.09.03.02.29.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 02:29:27 -0700 (PDT) Date: Mon, 3 Sep 2018 11:29:11 +0200 From: Adrien Mazarguil To: Christian Ehrhardt Cc: dev , Gowrishankar Muthukrishnan , Chao Zhu , Luca Boccassi , Thomas Monjalon Message-ID: <20180903092911.GU3695@6wind.com> References: <20180830115959.28935-1-christian.ehrhardt@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180830115959.28935-1-christian.ehrhardt@canonical.com> Subject: Re: [dpdk-dev] [PATCH v3] ppc64: fix compilation of when AltiVec is enabled 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: , X-List-Received-Date: Mon, 03 Sep 2018 09:29:28 -0000 Hi Christian, Couldn't follow up on this last week, however I still have some concerns and comments, please see below. On Thu, Aug 30, 2018 at 01:59:59PM +0200, Christian Ehrhardt wrote: > The definition of almost any newer standard like --stc=c11 will drop > __APPLCE_ALTIVEC__ which otherwise would be defined. > If that is the case then altivec.h will redefine bool to a type > conflicting with those defined by stdbool.h. > > This breaks compilation of 18.08 on ppc64 like: > mlx5_nl_flow.c:407:17: error: incompatible types when assigning > to type ‘__vector __bool int’ {aka ‘__vector(4) __bool int’} > from type ‘int’ in_port_id_set = false; > > Other alternatives were pursued on [1] but they always ended up being > more complex than what would be appropriate for the issue we face. > > [1]: http://mails.dpdk.org/archives/dev/2018-August/109926.html > > Tested-by: Takeshi T Yoshimura > Reviewed-by: Adrien Mazarguil > Signed-off-by: Christian Ehrhardt > --- > .../common/include/arch/ppc_64/rte_memcpy.h | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h b/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h > index 75f74897b..0b3b89b56 100644 > --- a/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h > +++ b/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h > @@ -37,6 +37,17 @@ > #include > /*To include altivec.h, GCC version must >= 4.8 */ > #include > +/* > + * Compilation workaround for PPC64 targets when AltiVec is fully > + * enabled e.g. with std=c11. Otherwise there would be a type conflict > + * of "bool" between stdbool and altivec. > + */ > +#if defined(__PPC64__) && !defined(__APPLE_ALTIVEC__) > + #undef bool > + /* redefine as in stdbool.h */ > + #define bool _Bool > +#endif > + The above will break existing C++ programs that include rte_memcpy.h. Problem is that bool is an actual C++ type. C99 has _Bool which doesn't exist in C++ along with a bool macro that appears only after including stdbool.h. To make things worse, nothing prevents C++ programs from importing a C-style bool macro by including stdbool.h (or cstdbool). Enclosing it in #ifdef __cplusplus won't help because you never know what bool is supposed to be in the first place as it depends on how applications are written. I think something like this prior suggestion [1] (saving/restoring bool) is the only way to deal with that in a safe-ish fashion. Pending something better, the above #undef/#define workaround is only safe to use inside mlx5 PMD code that triggers the compilation issue. It must not be found in a public header. > #ifdef __cplusplus > extern "C" { > -- > 2.17.1 > [1] https://mails.dpdk.org/archives/dev/2018-August/110401.html -- Adrien Mazarguil 6WIND