From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <christian.ehrhardt@canonical.com>
Received: from youngberry.canonical.com (youngberry.canonical.com
[91.189.89.112]) by dpdk.org (Postfix) with ESMTP id D1981231E
for <dev@dpdk.org>; Fri, 31 Aug 2018 07:14:58 +0200 (CEST)
Received: from mail-oi0-f71.google.com ([209.85.218.71])
by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
(Exim 4.76) (envelope-from <christian.ehrhardt@canonical.com>)
id 1fvblq-000245-Ft for dev@dpdk.org; Fri, 31 Aug 2018 05:14:58 +0000
Received: by mail-oi0-f71.google.com with SMTP id y135-v6so9749080oie.11
for <dev@dpdk.org>; Thu, 30 Aug 2018 22:14:58 -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=6n3jNaWjMa8ZxEGkr1hPv2ijJZBIVZA97o77fdaMGzM=;
b=mYeU9jHN8S9Vv2Imk94z9Gwh4Q6Tqm4/zPHXOHM7GXMlCoB1qJdJn0LOXQTP4jYjtE
uL90x/VKncZvoJqfQ7GlAvFJTnOFm+n9t0A4GxLOd3Az2uPUZuIru52i9fUMJGvwXgqs
BvcseM3wDJik1oXb6EABMpIiOh98E12tqY6p/BC//oOYIQ/J9hsqA3xhmmj4JuttZP+H
pNG8BbQijddtiJjrWwc+lF747EfEniCa7PB/rHmEsLp/rhNJQ9VqiAZdm+Ubp9OwMmxQ
I+X/bLXLQjwcC2Q059u+IbZQfmAoqDO3zs2YUaNaFsDD6YFxeSBPo64jhLPfAvaQJad1
uqwQ==
X-Gm-Message-State: APzg51ACdiE7560VOWjtlIk0sPIExB1mWFn7XEmnsA1I2/cQ+vQNnDgI
8KdXxVdZNm0fEnroW4hs8B5m6iZ2xI6H+hnXMFyEs3KwxB0ufjb2qfOTJAg3fQJ/8qyVm8+rbu6
98YaTQNgh/Se3sArJmeYbl+Yq/mblkqTmZEWI
X-Received: by 2002:aca:dbc2:: with SMTP id
s185-v6mr5859839oig.251.1535692497499;
Thu, 30 Aug 2018 22:14:57 -0700 (PDT)
X-Google-Smtp-Source: ANB0VdZ24FG5Jynt5C+3W6OaSK8Cfm+j/dUL+7QE5EFARhPfLz0HOuVeuXkSvrdC58NlU6YVqumRH/quQMmY1eFf9uk=
X-Received: by 2002:aca:dbc2:: with SMTP id
s185-v6mr5859832oig.251.1535692497294;
Thu, 30 Aug 2018 22:14:57 -0700 (PDT)
MIME-Version: 1.0
References: <20180830115959.28935-1-christian.ehrhardt@canonical.com>
<001c01d440cc$a84d20c0$f8e76240$@linux.vnet.ibm.com>
In-Reply-To: <001c01d440cc$a84d20c0$f8e76240$@linux.vnet.ibm.com>
From: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Date: Fri, 31 Aug 2018 07:14:31 +0200
Message-ID: <CAATJJ0+zQhCPz8E+bwUCOH7SqNozFEv+Ap6XdGpQubwU4pR3GQ@mail.gmail.com>
To: Chao Zhu <chaozhu@linux.vnet.ibm.com>
Cc: adrien.mazarguil@6wind.com, dev <dev@dpdk.org>,
Gowrishankar Muthukrishnan <gowrishankar.m@linux.vnet.ibm.com>,
Luca Boccassi <bluca@debian.org>, Thomas Monjalon <thomasm@mellanox.com>
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 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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Aug 2018 05:14:59 -0000
On Fri, Aug 31, 2018 at 3:48 AM Chao Zhu <chaozhu@linux.vnet.ibm.com> wrote=
:
> I think this patch is good enough to solve the confliction issue.
>
> > -----Original Message-----
> > From: Christian Ehrhardt [mailto:christian.ehrhardt@canonical.com]
> > Sent: 2018=E5=B9=B48=E6=9C=8830=E6=97=A5 20:00
> > To: adrien.mazarguil@6wind.com; dev <dev@dpdk.org>; Gowrishankar
> > Muthukrishnan <gowrishankar.m@linux.vnet.ibm.com>; Chao Zhu
> > <chaozhu@linux.vnet.ibm.com>
> > Cc: Luca Boccassi <bluca@debian.org>; Thomas Monjalon
> > <thomasm@mellanox.com>; Christian Ehrhardt
> > <christian.ehrhardt@canonical.com>
> > Subject: [PATCH v3] ppc64: fix compilation of when AltiVec is enabled
> >
> > 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 <TYOS@jp.ibm.com>
> > Reviewed-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> > ---
> > .../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 <string.h>
> > /*To include altivec.h, GCC version must >=3D 4.8 */ #include
> <altivec.h>
> > +/*
> > + * Compilation workaround for PPC64 targets when AltiVec is fully
> > + * enabled e.g. with std=3Dc11. Otherwise there would be a type confli=
ct
> > + * 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
> Acked-by: Chao Zhu <chaozhu@linux.vnet.ibm.com>
>
Thanks Chao for taking over for now.
Being listed as Maintainer for "IBM Power" atm, can you push this yourself
or do you need someone else to commit it?
--=20
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd