[v2] eal/ppc: fix redefine bool type
Checks
Commit Message
The AltiVec header file breaks boolean type. [1] [2]
Currently the workaround was located only in mlx5 device.
Adding the trace module caused this issue to appear again, due to
order of includes, it keeps overriding the local fix.
This patch solves this issue by resetting the bool type, immediately
after it is being changed.
[1] https://mails.dpdk.org/archives/dev/2018-August/110281.html
[2]
In file included from
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:18:0,
from
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool.h:54,
from
dpdk/drivers/common/mlx5/mlx5_common_mr.c:7:
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h: In
function '__rte_trace_point_fp_is_enabled':
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:226:2:
error: incompatible types when returning type 'int' but '__vector __bool
int' was expected
return false;
^
In file included from
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:281:0,
from
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:18,
from
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool.h:54,
from
dpdk/drivers/common/mlx5/mlx5_common_mr.c:7:
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:
In function 'rte_mempool_trace_ops_dequeue_bulk':
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point_provider.h:104:6:
error: wrong type argument to unary exclamation mark
if (!__rte_trace_point_fp_is_enabled()) \
^
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:49:2:
note: in expansion of macro '__rte_trace_point_emit_header_fp'
__rte_trace_point_emit_header_##_mode(&__##_tp); \
^
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:99:2:
note: in expansion of macro '__RTE_TRACE_POINT'
__RTE_TRACE_POINT(fp, tp, args, __VA_ARGS__)
^
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:20:1:
note: in expansion of macro 'RTE_TRACE_POINT_FP'
RTE_TRACE_POINT_FP(
^
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:
In function 'rte_mempool_trace_ops_dequeue_contig_blocks':
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point_provider.h:104:6:
error: wrong type argument to unary exclamation mark
if (!__rte_trace_point_fp_is_enabled()) \
^
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:49:2:
note: in expansion of macro '__rte_trace_point_emit_header_fp'
__rte_trace_point_emit_header_##_mode(&__##_tp); \
^
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:99:2:
note: in expansion of macro '__RTE_TRACE_POINT'
__RTE_TRACE_POINT(fp, tp, args, __VA_ARGS__)
^
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:29:1:
note: in expansion of macro 'RTE_TRACE_POINT_FP'
RTE_TRACE_POINT_FP(
^
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:
In function 'rte_mempool_trace_ops_enqueue_bulk':
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point_provider.h:104:6:
error: wrong type argument to unary exclamation mark
if (!__rte_trace_point_fp_is_enabled()) \
Fixes: 725f5dd0bfb5 ("net/mlx5: fix build on PPC64")
Signed-off-by: Ori Kam <orika@mellanox.com>
Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
---
v2:
* Replace alitvec include in all files.
* Address ML comments.
---
drivers/common/mlx5/mlx5_common.h | 10 ----------
drivers/net/i40e/i40e_rxtx_vec_altivec.c | 2 +-
drivers/net/mlx5/mlx5_rxtx_vec_altivec.h | 2 +-
drivers/net/mlx5/mlx5_utils.h | 10 ----------
drivers/net/virtio/virtio_rxtx_simple_altivec.c | 2 +-
lib/librte_eal/ppc/include/meson.build | 1 +
lib/librte_eal/ppc/include/rte_altivec.h | 22 ++++++++++++++++++++++
lib/librte_eal/ppc/include/rte_memcpy.h | 3 +--
lib/librte_eal/ppc/include/rte_vect.h | 2 +-
9 files changed, 28 insertions(+), 26 deletions(-)
create mode 100644 lib/librte_eal/ppc/include/rte_altivec.h
Comments
On 4/30/20 7:22 AM, Ori Kam wrote:
> The AltiVec header file breaks boolean type. [1] [2]
>
> Currently the workaround was located only in mlx5 device.
> Adding the trace module caused this issue to appear again, due to
> order of includes, it keeps overriding the local fix.
>
> This patch solves this issue by resetting the bool type, immediately
> after it is being changed.
...
> Fixes: 725f5dd0bfb5 ("net/mlx5: fix build on PPC64")
>
> Signed-off-by: Ori Kam <orika@mellanox.com>
> Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
> ---
> v2:
> * Replace alitvec include in all files.
> * Address ML comments.
> ---
Tested-by: David Christensen <drc@linux.vnet.ibm.com>
Hi,
> -----Original Message-----
> From: David Christensen <drc@linux.vnet.ibm.com>
> Sent: Thursday, April 30, 2020 10:41 PM
> To: Ori Kam <orika@mellanox.com>; Thomas Monjalon
> <thomas@monjalon.net>; Matan Azrad <matan@mellanox.com>; Shahaf
> Shuler <shahafs@mellanox.com>; Slava Ovsiienko
> <viacheslavo@mellanox.com>; Beilei Xing <beilei.xing@intel.com>; Qi Zhang
> <qi.z.zhang@intel.com>; Maxime Coquelin
> <maxime.coquelin@redhat.com>; Zhihong Wang
> <zhihong.wang@intel.com>; Xiaolong Ye <xiaolong.ye@intel.com>
> Cc: Raslan Darawsheh <rasland@mellanox.com>;
> david.marchand@redhat.com; dev@dpdk.org; ferruh.yigit@intel.com
> Subject: Re: [PATCH v2] eal/ppc: fix redefine bool type
>
>
>
> On 4/30/20 7:22 AM, Ori Kam wrote:
> > The AltiVec header file breaks boolean type. [1] [2]
> >
> > Currently the workaround was located only in mlx5 device.
> > Adding the trace module caused this issue to appear again, due to
> > order of includes, it keeps overriding the local fix.
> >
> > This patch solves this issue by resetting the bool type, immediately
> > after it is being changed.
> ...
> > Fixes: 725f5dd0bfb5 ("net/mlx5: fix build on PPC64")
> >
> > Signed-off-by: Ori Kam <orika@mellanox.com>
> > Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
> > ---
> > v2:
> > * Replace alitvec include in all files.
> > * Address ML comments.
> > ---
> Tested-by: David Christensen <drc@linux.vnet.ibm.com>
Tested-by: Raslan Darawsheh <rasland@mellanox.com>
Kindest regards,
Raslan Darawsheh
From: Raslan Darawsheh
> Hi,
>
> > -----Original Message-----
> > From: David Christensen <drc@linux.vnet.ibm.com>
> > Sent: Thursday, April 30, 2020 10:41 PM
> > To: Ori Kam <orika@mellanox.com>; Thomas Monjalon
> > <thomas@monjalon.net>; Matan Azrad <matan@mellanox.com>; Shahaf
> Shuler
> > <shahafs@mellanox.com>; Slava Ovsiienko <viacheslavo@mellanox.com>;
> > Beilei Xing <beilei.xing@intel.com>; Qi Zhang <qi.z.zhang@intel.com>;
> > Maxime Coquelin <maxime.coquelin@redhat.com>; Zhihong Wang
> > <zhihong.wang@intel.com>; Xiaolong Ye <xiaolong.ye@intel.com>
> > Cc: Raslan Darawsheh <rasland@mellanox.com>;
> > david.marchand@redhat.com; dev@dpdk.org; ferruh.yigit@intel.com
> > Subject: Re: [PATCH v2] eal/ppc: fix redefine bool type
> >
> >
> >
> > On 4/30/20 7:22 AM, Ori Kam wrote:
> > > The AltiVec header file breaks boolean type. [1] [2]
> > >
> > > Currently the workaround was located only in mlx5 device.
> > > Adding the trace module caused this issue to appear again, due to
> > > order of includes, it keeps overriding the local fix.
> > >
> > > This patch solves this issue by resetting the bool type, immediately
> > > after it is being changed.
> > ...
> > > Fixes: 725f5dd0bfb5 ("net/mlx5: fix build on PPC64")
> > >
> > > Signed-off-by: Ori Kam <orika@mellanox.com>
> > > Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
> > > ---
> > > v2:
> > > * Replace alitvec include in all files.
> > > * Address ML comments.
> > > ---
> > Tested-by: David Christensen <drc@linux.vnet.ibm.com>
> Tested-by: Raslan Darawsheh <rasland@mellanox.com>
Acked-by: Matan Azrad <matan@mellanox.com>
>
> Kindest regards,
> Raslan Darawsheh
On Thu, Apr 30, 2020 at 4:22 PM Ori Kam <orika@mellanox.com> wrote:
>
> The AltiVec header file breaks boolean type. [1] [2]
>
> Currently the workaround was located only in mlx5 device.
> Adding the trace module caused this issue to appear again, due to
> order of includes, it keeps overriding the local fix.
>
> This patch solves this issue by resetting the bool type, immediately
> after it is being changed.
>
> [1] https://mails.dpdk.org/archives/dev/2018-August/110281.html
>
> [2]
> In file included from
> dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:18:0,
> from
> dpdk/ppc_64-power8-linux-gcc/include/rte_mempool.h:54,
> from
> dpdk/drivers/common/mlx5/mlx5_common_mr.c:7:
> dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h: In
> function '__rte_trace_point_fp_is_enabled':
> dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:226:2:
> error: incompatible types when returning type 'int' but '__vector __bool
> int' was expected
> return false;
> ^
> In file included from
> dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:281:0,
> from
> dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:18,
> from
> dpdk/ppc_64-power8-linux-gcc/include/rte_mempool.h:54,
> from
> dpdk/drivers/common/mlx5/mlx5_common_mr.c:7:
> dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:
> In function 'rte_mempool_trace_ops_dequeue_bulk':
> dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point_provider.h:104:6:
> error: wrong type argument to unary exclamation mark
> if (!__rte_trace_point_fp_is_enabled()) \
> ^
> dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:49:2:
> note: in expansion of macro '__rte_trace_point_emit_header_fp'
> __rte_trace_point_emit_header_##_mode(&__##_tp); \
> ^
> dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:99:2:
> note: in expansion of macro '__RTE_TRACE_POINT'
> __RTE_TRACE_POINT(fp, tp, args, __VA_ARGS__)
> ^
> dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:20:1:
> note: in expansion of macro 'RTE_TRACE_POINT_FP'
> RTE_TRACE_POINT_FP(
> ^
> dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:
> In function 'rte_mempool_trace_ops_dequeue_contig_blocks':
> dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point_provider.h:104:6:
> error: wrong type argument to unary exclamation mark
> if (!__rte_trace_point_fp_is_enabled()) \
> ^
> dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:49:2:
> note: in expansion of macro '__rte_trace_point_emit_header_fp'
> __rte_trace_point_emit_header_##_mode(&__##_tp); \
> ^
> dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:99:2:
> note: in expansion of macro '__RTE_TRACE_POINT'
> __RTE_TRACE_POINT(fp, tp, args, __VA_ARGS__)
> ^
> dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:29:1:
> note: in expansion of macro 'RTE_TRACE_POINT_FP'
> RTE_TRACE_POINT_FP(
> ^
> dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:
> In function 'rte_mempool_trace_ops_enqueue_bulk':
> dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point_provider.h:104:6:
> error: wrong type argument to unary exclamation mark
> if (!__rte_trace_point_fp_is_enabled()) \
>
> Fixes: 725f5dd0bfb5 ("net/mlx5: fix build on PPC64")
>
> Signed-off-by: Ori Kam <orika@mellanox.com>
> Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
Tested-by: David Christensen <drc@linux.vnet.ibm.com>
Tested-by: Raslan Darawsheh <rasland@mellanox.com>
Acked-by: Matan Azrad <matan@mellanox.com>
Applied, thanks.
@@ -17,16 +17,6 @@
#include "mlx5_prm.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)) + \
@@ -13,7 +13,7 @@
#include "i40e_rxtx.h"
#include "i40e_rxtx_vec_common.h"
-#include <altivec.h>
+#include "rte_altivec.h"
#pragma GCC diagnostic ignored "-Wcast-qual"
@@ -10,7 +10,7 @@
#include <string.h>
#include <stdlib.h>
-#include <altivec.h>
+#include "rte_altivec.h"
#include <rte_mbuf.h>
#include <rte_mempool.h>
@@ -21,16 +21,6 @@
#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
-
/* Convert a bit number to the corresponding 64-bit mask */
#define MLX5_BITSHIFT(v) (UINT64_C(1) << (v))
@@ -9,7 +9,7 @@
#include <string.h>
#include <errno.h>
-#include <altivec.h>
+#include "rte_altivec.h"
#include <rte_byteorder.h>
#include <rte_branch_prediction.h>
@@ -4,6 +4,7 @@
includes += include_directories('.')
arch_headers = files(
+ 'rte_altivec.h',
'rte_atomic.h',
'rte_byteorder.h',
'rte_cpuflags.h',
new file mode 100644
@@ -0,0 +1,22 @@
+/*
+ * SPDX-License-Identifier: BSD-3-Clause
+ * Copyright (C) Mellanox 2020.
+ */
+
+#ifndef _RTE_ALTIVEC_H_
+#define _RTE_ALTIVEC_H_
+
+/* To include altivec.h, GCC version must be >= 4.8 */
+#include <altivec.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
+
+#endif /* _RTE_ALTIVEC_H_ */
@@ -8,8 +8,7 @@
#include <stdint.h>
#include <string.h>
-/*To include altivec.h, GCC version must >= 4.8 */
-#include <altivec.h>
+#include "rte_altivec.h"
#ifdef __cplusplus
extern "C" {
@@ -6,7 +6,7 @@
#ifndef _RTE_VECT_PPC_64_H_
#define _RTE_VECT_PPC_64_H_
-#include <altivec.h>
+#include "rte_altivec.h"
#include "generic/rte_vect.h"
#include "rte_common.h"