[dpdk-dev] [PATCH v3] ppc64: fix compilation of when AltiVec is enabled

[dpdk-dev] [PATCH v3] ppc64: fix compilation of when AltiVec is enabled

[Christian Ehrhardt]

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 <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  >= 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

Re: [dpdk-dev] [PATCH v3] ppc64: fix compilation of when AltiVec is enabled

[Chao Zhu]

I think this patch is good enough to solve the confliction issue.

> -----Original Message-----
> From: Christian Ehrhardt [mailto:christian.ehrhardt@canonical.com]
> Sent: 2018年8月30日 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=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 <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  >= 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
Acked-by: Chao Zhu <chaozhu@linux.vnet.ibm.com>

Re: [dpdk-dev] [PATCH v3] ppc64: fix compilation of when AltiVec is enabled

[Christian Ehrhardt]

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年8月30日 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=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 <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  >= 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
> 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?

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Re: [dpdk-dev] [PATCH v3] ppc64: fix compilation of when AltiVec is enabled

[Chao Zhu]

We’ll have internal discussion and push it.

Thanks!

 

From: Christian Ehrhardt [mailto:christian.ehrhardt@canonical.com] 
Sent: 2018年8月31日 13:15
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>
Subject: Re: [PATCH v3] ppc64: fix compilation of when AltiVec is enabled

 

 

On Fri, Aug 31, 2018 at 3:48 AM Chao Zhu <chaozhu@linux.vnet.ibm.com <mailto: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 <mailto:christian.ehrhardt@canonical.com> ]
> Sent: 2018年8月30日 20:00
> To: adrien.mazarguil@6wind.com <mailto:adrien.mazarguil@6wind.com> ; dev <dev@dpdk.org <mailto:dev@dpdk.org> >; Gowrishankar
> Muthukrishnan <gowrishankar.m@linux.vnet.ibm.com <mailto:gowrishankar.m@linux.vnet.ibm.com> >; Chao Zhu
> <chaozhu@linux.vnet.ibm.com <mailto:chaozhu@linux.vnet.ibm.com> >
> Cc: Luca Boccassi <bluca@debian.org <mailto:bluca@debian.org> >; Thomas Monjalon
> <thomasm@mellanox.com <mailto:thomasm@mellanox.com> >; Christian Ehrhardt
> <christian.ehrhardt@canonical.com <mailto:christian.ehrhardt@canonical.com> >
> Subject: [PATCH v3] 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]: http://mails.dpdk.org/archives/dev/2018-August/109926.html
> 
> Tested-by: Takeshi T Yoshimura <TYOS@jp.ibm.com <mailto:TYOS@jp.ibm.com> >
> Reviewed-by: Adrien Mazarguil <adrien.mazarguil@6wind.com <mailto:adrien.mazarguil@6wind.com> >
> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com <mailto: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
Acked-by: Chao Zhu <chaozhu@linux.vnet.ibm.com <mailto: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?

 

-- 

Christian Ehrhardt

Software Engineer, Ubuntu Server

Canonical Ltd

Re: [dpdk-dev] [PATCH v3] ppc64: fix compilation of when AltiVec is enabled

[Adrien Mazarguil]

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 <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  >= 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
> +

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

Re: [dpdk-dev] [PATCH v3] ppc64: fix compilation of when AltiVec is enabled

[Thomas Monjalon]

03/09/2018 11:29, Adrien Mazarguil:
> 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 <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(+)
> > 
> > --- 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
> > +
> 
> 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" {
> 
> [1] https://mails.dpdk.org/archives/dev/2018-August/110401.html

Thank you for the review Adrien. I think we could accept the patch
if some notes mention it breaks C++ applications.
But...
After 2 months, nobody replied or complained about the issue not fixed.
So I classify this patch as rejected.

Summary of alerts here:
	http://mails.dpdk.org/archives/dev/2018-November/118259.html

[dpdk-dev] [PATCH] net/mlx5: fix build on PPC64

[Thomas Monjalon]

The AltiVec header file breaks boolean type:

error: incompatible types when initializing type
'__vector _bool int' {aka '_vector(4) __bool int'} using type 'int'

If __APPLE_ALTIVEC__ is defined, then bool type is redefined
and conflicts with stdbool.h.

There is no good solution to fix it for the whole project without
breaking something else, so a workaround is inserted in mlx5 PMD.
This workaround is not compatible with C++ but there is no C++ in DPDK.

Suggested-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Suggested-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
 drivers/net/mlx5/mlx5_utils.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_utils.h b/drivers/net/mlx5/mlx5_utils.h
index 886f60e61..97092c749 100644
--- a/drivers/net/mlx5/mlx5_utils.h
+++ b/drivers/net/mlx5/mlx5_utils.h
@@ -15,6 +15,16 @@
 
 #include "mlx5_defs.h"
 
+/*
+ * Compilation workaround for PPC64 when AltiVec is fully enabled, e.g. std=c11.
+ * Otherwise there would be a type conflict between stdbool and altivec.
+ */
+#if defined(__PPC64__) && !defined(__APPLE_ALTIVEC__)
+#undef bool
+/* redefine as in stdbool.h */
+#define bool _Bool
+#endif
+
 /* Bit-field manipulation. */
 #define BITFIELD_DECLARE(bf, type, size) \
 	type bf[(((size_t)(size) / (sizeof(type) * CHAR_BIT)) + \
-- 
2.19.0

Re: [dpdk-dev] [PATCH] net/mlx5: fix build on PPC64

[dwilder]

On 2018-11-07 08:00, Thomas Monjalon wrote:
> The AltiVec header file breaks boolean type:
> 
> error: incompatible types when initializing type
> '__vector _bool int' {aka '_vector(4) __bool int'} using type 'int'
> 
> If __APPLE_ALTIVEC__ is defined, then bool type is redefined
> and conflicts with stdbool.h.
> 
> There is no good solution to fix it for the whole project without
> breaking something else, so a workaround is inserted in mlx5 PMD.
> This workaround is not compatible with C++ but there is no C++ in DPDK.
> 
> Suggested-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> Suggested-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>

<cut ....>

Tested-by: David Wilder <dwilder@us.ibm.com>

Hi Thomas

Thanks for re-posting this patch.  I see no build breaks on power8 or 
power9 with this patch.  I tried both 18.11-rc1 and upstream (master).

Re: [dpdk-dev] [PATCH] net/mlx5: fix build on PPC64

[Thomas Monjalon]

07/11/2018 20:05, dwilder:
> On 2018-11-07 08:00, Thomas Monjalon wrote:
> > The AltiVec header file breaks boolean type:
> > 
> > error: incompatible types when initializing type
> > '__vector _bool int' {aka '_vector(4) __bool int'} using type 'int'
> > 
> > If __APPLE_ALTIVEC__ is defined, then bool type is redefined
> > and conflicts with stdbool.h.
> > 
> > There is no good solution to fix it for the whole project without
> > breaking something else, so a workaround is inserted in mlx5 PMD.
> > This workaround is not compatible with C++ but there is no C++ in DPDK.
> > 
> > Suggested-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> > Suggested-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> 
> <cut ....>
> 
> Tested-by: David Wilder <dwilder@us.ibm.com>
> 
> Hi Thomas
> 
> Thanks for re-posting this patch.  I see no build breaks on power8 or 
> power9 with this patch.  I tried both 18.11-rc1 and upstream (master).

It is not really a re-post. I took the last solution which was
proposed for EAL, and applied it to mlx5 only.

Re: [dpdk-dev] [PATCH] net/mlx5: fix build on PPC64

[Shahaf Shuler]

Wednesday, November 7, 2018 11:10 PM, Thomas Monjalon:
> Subject: Re: [PATCH] net/mlx5: fix build on PPC64
> 
> 07/11/2018 20:05, dwilder:
> > On 2018-11-07 08:00, Thomas Monjalon wrote:
> > > The AltiVec header file breaks boolean type:
> > >
> > > error: incompatible types when initializing type '__vector _bool
> > > int' {aka '_vector(4) __bool int'} using type 'int'
> > >
> > > If __APPLE_ALTIVEC__ is defined, then bool type is redefined and
> > > conflicts with stdbool.h.
> > >
> > > There is no good solution to fix it for the whole project without
> > > breaking something else, so a workaround is inserted in mlx5 PMD.
> > > This workaround is not compatible with C++ but there is no C++ in DPDK.
> > >
> > > Suggested-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> > > Suggested-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> >
> > <cut ....>
> >
> > Tested-by: David Wilder <dwilder@us.ibm.com>
> >
> > Hi Thomas
> >
> > Thanks for re-posting this patch.  I see no build breaks on power8 or
> > power9 with this patch.  I tried both 18.11-rc1 and upstream (master).
> 
> It is not really a re-post. I took the last solution which was proposed for EAL,
> and applied it to mlx5 only.

Applied to next-net-mlx, thanks. 

> 

´ð¸´: [PATCH] net/mlx5: fix build on PPC64

[Chao Zhu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]

> -----ÓʼþÔ­¼þ-----
> ·¢¼þÈË: Thomas Monjalon <thomas@monjalon.net>
> ·¢ËÍʱ¼ä: 2018Äê11ÔÂ8ÈÕ 0:00
> ÊÕ¼þÈË: dev@dpdk.org
> ³­ËÍ: christian.ehrhardt@canonical.com; adrien.mazarguil@6wind.com;
> shahafs@mellanox.com; yskoh@mellanox.com;
> gowrishankar.m@linux.vnet.ibm.com; chaozhu@linux.vnet.ibm.com;
> pradeep@us.ibm.com; tyos@jp.ibm.com; dwilder@us.ibm.com
> Ö÷Ìâ: [PATCH] net/mlx5: fix build on PPC64
>
> The AltiVec header file breaks boolean type:
>
> error: incompatible types when initializing type '__vector _bool int' {aka
> '_vector(4) __bool int'} using type 'int'
>
> If __APPLE_ALTIVEC__ is defined, then bool type is redefined and conflicts
> with stdbool.h.
>
> There is no good solution to fix it for the whole project without breaking
> something else, so a workaround is inserted in mlx5 PMD.
> This workaround is not compatible with C++ but there is no C++ in DPDK.
>
> Suggested-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> Suggested-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
>  drivers/net/mlx5/mlx5_utils.h | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/mlx5/mlx5_utils.h b/drivers/net/mlx5/mlx5_utils.h
> index 886f60e61..97092c749 100644
> --- a/drivers/net/mlx5/mlx5_utils.h
> +++ b/drivers/net/mlx5/mlx5_utils.h
> @@ -15,6 +15,16 @@
>
>  #include "mlx5_defs.h"
>
> +/*
> + * Compilation workaround for PPC64 when AltiVec is fully enabled, e.g.
> std=c11.
> + * Otherwise there would be a type conflict between stdbool and altivec.
> + */
> +#if defined(__PPC64__) && !defined(__APPLE_ALTIVEC__) #undef bool
> +/* redefine as in stdbool.h */
> +#define bool _Bool
> +#endif
> +
>  /* Bit-field manipulation. */
>  #define BITFIELD_DECLARE(bf, type, size) \
>  	type bf[(((size_t)(size) / (sizeof(type) * CHAR_BIT)) + \
> --
> 2.19.0
Verified, it works. Thanks!

Acked-by: Chao Zhu <chaozhu@linux.vnet.ibm.com>