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

Change-Id: I1ed56da954e4951b9d120ca2ac0c0c218b4a0140
Signed-off-by: Christian Ehrhardt <redacted>
---
 .../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