From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by dpdk.org (Postfix) with ESMTP id C5FD02BF7 for ; Thu, 30 Aug 2018 13:59:44 +0200 (CEST) Received: from mail-oi0-f69.google.com ([209.85.218.69]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1fvLc0-0006Aq-Jg for dev@dpdk.org; Thu, 30 Aug 2018 11:59:44 +0000 Received: by mail-oi0-f69.google.com with SMTP id b8-v6so7259441oib.4 for ; Thu, 30 Aug 2018 04:59:44 -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=3dnLH0eak7MYBAg3oVekSwwXEEcRJ/ZjUAaAHx3m5K4=; b=bXWxVAG586kt9RCO1NJanqN855tuArDClCc/+YFE9wSGCasXlhESwgwPkkzndXnP3j EhxqIf0zPzmGeoNHoO9nS0iImXSCprwzHGQ6E3CQp7NH4qnaCPgslJVUuea/KiSStydo c48GrEcv04KwNPuFiTxNlQfZyprTXy0b4XsaZTNzZ6k+isGKZLf7HSCaHoVx9PwH4Uqy x+vryXCkUzJnFMi3JCKGYIhDWKU1CRkbaqMPniVx+mcXgzkNxUuFeskPoaMamnQl0rWD AimAQ/Gli+ho6PRx8Cym3/bFzi/Pmm8KLUV2vrR2HlSBDBOk1uTExYLicMxFG4OIummz gsCQ== X-Gm-Message-State: APzg51C0N7fzKKHKLi6jW+NciO6JV/nfeilvKk428kl2yhrUgf4hZj7f Bn5y7HPCgQQ7Xp2vWDikr2uWHCaiS/XpfhjjI3yYjMfs8vHx+01SJ1rxY2Q7UCqItgNP+vQHdBx 0xb+yJrwUu8IAwm1tU1YlEJgmNBAL6NnA9cck X-Received: by 2002:aca:b702:: with SMTP id h2-v6mr2334933oif.66.1535630383619; Thu, 30 Aug 2018 04:59:43 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbjNEDNHJ4VrgT5jHAj95PvmmyJ7ZwnVRcum0kwgF8+hVaHSIjUI7TK1esLhJ0xodqRP9kghHDfrJmdEnQo4xk= X-Received: by 2002:aca:b702:: with SMTP id h2-v6mr2334925oif.66.1535630383459; Thu, 30 Aug 2018 04:59:43 -0700 (PDT) MIME-Version: 1.0 References: <20180830115504.28608-1-christian.ehrhardt@canonical.com> In-Reply-To: <20180830115504.28608-1-christian.ehrhardt@canonical.com> From: Christian Ehrhardt Date: Thu, 30 Aug 2018 13:59:17 +0200 Message-ID: To: adrien.mazarguil@6wind.com, dev , Gowrishankar Muthukrishnan , Chao Zhu Cc: Luca Boccassi , Thomas Monjalon Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v2] 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: Thu, 30 Aug 2018 11:59:44 -0000 On Thu, Aug 30, 2018 at 1:55 PM Christian Ehrhardt < christian.ehrhardt@canonical.com> wrote: > The definition of almost any newer standard like --stc=3Dc11 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 =E2=80=98__vector __bool int=E2=80=99 {aka =E2=80=98__vector(4)= __bool int=E2=80=99} > from type =E2=80=98int=E2=80=99 in_port_id_set =3D 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 adrien.mazarguil@6wind.com After more of a decade of submitting patches I should get an email right :-= / Well V3 it will be ... > 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 >=3D 4.8 */ > #include > +/* > + * Compilation workaround for PPC64 targets when AltiVec is fully > + * enabled e.g. with std=3Dc11. 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 > + > > #ifdef __cplusplus > extern "C" { > -- > 2.17.1 > > --=20 Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd