Re: [dpdk-dev] [EXT] [PATCH 1/3] acl: fix arm argument types

[Jerin Jacob Kollanukkaran <jerinj@marvell.com>]

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@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 ?