Re: [PATCH] ppc64: fix compilation of when AltiVec is enabled

[Christian Ehrhardt <christian.ehrhardt@canonical.com>]

On Thu, Aug 30, 2018 at 12:52 PM Takeshi T Yoshimura <TYOS@jp.ibm.com>
wrote:

> >宛先: adrien.mazarguil@6wind.com, dev <dev@dpdk.org>, Gowrishankar
> >Muthukrishnan <gowrishankar.m@linux.vnet.ibm.com>, Chao Zhu
> ><chaozhu@linux.vnet.ibm.com>
> >送信元: Christian Ehrhardt
> >送信者: "dev"
> >日付: 2018/08/30 07:00PM
> >Cc: Luca Boccassi <bluca@debian.org>, Thomas Monjalon
> ><thomasm@mellanox.com>, Christian Ehrhardt
> ><christian.ehrhardt@canonical.com>
> >件名: [dpdk-dev] [PATCH] ppc64: fix compilation of when AltiVec is
> >enabled
> >
> >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]:
> >INVALID URI REMOVED
> >chives_dev_2018-2DAugust_109926.html&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZO
> >g&r=EZR6Jx10q0q3dTopeH3WIQ&m=bbU1KVc1ZvNW9Rz7B0MLHfS0f0oZv35d2mpRpHO0
> >ByY&s=RvMIFfk-cAAGTrYM76-iSSqIYV_X2EptYZzYIweIHRk&e=
> >
> >Change-Id: I1ed56da954e4951b9d120ca2ac0c0c218b4a0140
> >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  >= 4.8 */
> > #include <altivec.h>
> >+/*
> >+ * 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
> >+
> >
> > #ifdef __cplusplus
> > extern "C" {
> >--
> >2.17.1
> >
> >
> >
>
> Hi,
> I could reproduce the issue you reported in 18.08 with my ppc64le box with
> RedHat 7.5 and GCC4.8.
> The patch resolved the issue in my environment. Thanks!
>

I added your test (tanks) and Adrien's extensive review/discussion as tags
and also addressed a few checkpatch findings.
V2 is up on the list now ...


> I am a bit newbie in dpdk-dev, but I will try contacting Chao and other
> IBM guys... Sorry for our slow reply.
>

Thanks for your participation Takeshi,
we at least now have had a few replies after Thomas used the superpowers of
"CPT. CAPSLOCK" \o/.

I also have a call later today to make sure this is brought up inside IBM
to make sure someone is maintaining it for real.


> Regards,
> Takeshi
>
>

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd