[dpdk-dev] [EXT] [PATCH 1/3] acl: fix arm argument types
Jerin Jacob Kollanukkaran
jerinj at marvell.com
Wed Apr 10 16:39:31 CEST 2019
On Mon, 2019-04-08 at 14:24 -0400, Aaron Conole wrote:
> -------------------------------------------------------------------
> ---
> Compiler complains of argument type mismatch, like:
Can you share more details on how to reproduce this issue?
We already have
CFLAGS_acl_run_neon.o += -flax-vector-conversions
in the Makefile.
If you are taking out -flax-vector-conversions the correct way to
fix will be use vreinterpret*.
For me the code looks clean, If unnecessary casting is avoided.
>
> ../lib/librte_acl/acl_run_neon.h: In function ‘transition4’:
> ../lib/librte_acl/acl_run_neon.h:115:2: note: use -flax-vector-
> conversions
> to permit conversions between vectors with differing element
> types
> or numbers of subparts
> node_type = vbicq_s32(tr_hi_lo.val[0], index_msk);
> ^
> ../lib/librte_acl/acl_run_neon.h:115:41: error: incompatible type
> for
> argument 2 of ‘vbicq_s32’
>
> Signed-off-by: Aaron Conole <aconole at redhat.com>
> ---
> lib/librte_acl/acl_run_neon.h | 46 ++++++++++++++++++++-------------
> --
> 1 file changed, 27 insertions(+), 19 deletions(-)
>
>
>
> /*
> @@ -179,6 +183,9 @@ search_neon_8(const struct rte_acl_ctx *ctx,
> const uint8_t **data,
> acl_match_check_x4(0, ctx, parms, &flows, &index_array[0]);
> acl_match_check_x4(4, ctx, parms, &flows, &index_array[4]);
>
> + memset(&input0, 0, sizeof(input0));
> + memset(&input1, 0, sizeof(input1));
Why this memset only required for arm64? If it real issue, Shouldn't
it required for x86 and ppc ?
More information about the dev
mailing list