From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 913F8A0096 for ; Wed, 5 Jun 2019 22:59:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A9F0D1B9BC; Wed, 5 Jun 2019 22:59:08 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id D61701B957 for ; Wed, 5 Jun 2019 22:59:06 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DE07A99C1D; Wed, 5 Jun 2019 20:58:50 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E5622619A9; Wed, 5 Jun 2019 20:58:46 +0000 (UTC) From: Aaron Conole To: Thomas Monjalon Cc: honnappa.nagarahalli@arm.com, ruifeng.wang@arm.com, gavin.hu@arm.com, dharmik.thakkar@arm.com, jerin.jacob@caviumnetworks.com, Yongseok Koh , dev@dpdk.org, msantana@redhat.com, bruce.richardson@intel.com References: <18576498.0Zn3BvHS7Y@xps> <74282465.H2CcKukIUE@xps> Date: Wed, 05 Jun 2019 16:58:46 -0400 In-Reply-To: <74282465.H2CcKukIUE@xps> (Thomas Monjalon's message of "Wed, 05 Jun 2019 22:04:53 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 05 Jun 2019 20:59:01 +0000 (UTC) Subject: Re: [dpdk-dev] DPDK compilation on arm is failing in Travis X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Thomas Monjalon writes: > 05/06/2019 21:40, Aaron Conole: >> Thomas Monjalon writes: >> >> > The compilation of the master branch is failing for aarch64: >> > https://travis-ci.com/DPDK/dpdk >> > The log is so much verbose that I am not able to understand >> > what is really wrong. >> > Please help to diagnose and fix, thanks. >> >> A discussion about this: >> >> http://mails.dpdk.org/archives/dev/2019-June/134012.html > > I see the error now. > It is printing the full log after the error, > so I missed the error at the top. > > I've read your comment about a possible error with the patch > removing weak functions but neither me nor Bruce were able > to reproduce it. What is the condition to see this compiler warning? It is only on ARM, and only when the neon intrinsics are in use. The issue is the vector lane setting code looks like: lval = lane_set(scalar, rval, lane id) In this case, 'rval' is being used before it is ever set, but it really could be just 0 for the first lane setting code. Thereafter, we use the old value of input as the rval, but each time a different lane is set. It would be nice if there were an intrinsic that formatted correctly from the start (something we could call like lval = lane_set_from_array(scalar_array)). Then 'input' would never appear as an rval before it was set. I thought Jerin Jacob (CC'd) would have some opinion on the right fix. There are three 'fixes' I know exist - one is to squelch the warning (but I don't like it because it could hide future code that introduces this), one is to create a static and use assignment, one is to replace the first call and pass in a 0'd lane for the first one. Actually, I think I have a patch that could work to not introduce an assignment, but squelch the warning. Something like the following (not tested). --- diff --git a/lib/librte_acl/acl_run_neon.h b/lib/librte_acl/acl_run_neon.h index 01b9766d8..37c984fef 100644 --- a/lib/librte_acl/acl_run_neon.h +++ b/lib/librte_acl/acl_run_neon.h @@ -165,6 +165,7 @@ search_neon_8(const struct rte_acl_ctx *ctx, const uint8_t **data, uint64_t index_array[8]; struct completion cmplt[8]; struct parms parms[8]; + static int32x4_t ZEROVAL; int32x4_t input0, input1; acl_set_flow(&flows, cmplt, RTE_DIM(cmplt), data, results, @@ -181,8 +182,8 @@ search_neon_8(const struct rte_acl_ctx *ctx, const uint8_t **data, while (flows.started > 0) { /* Gather 4 bytes of input data for each stream. */ - input0 = vsetq_lane_s32(GET_NEXT_4BYTES(parms, 0), input0, 0); - input1 = vsetq_lane_s32(GET_NEXT_4BYTES(parms, 4), input1, 0); + input0 = vsetq_lane_s32(GET_NEXT_4BYTES(parms, 0), ZEROVAL, 0); + input1 = vsetq_lane_s32(GET_NEXT_4BYTES(parms, 4), ZEROVAL, 0); input0 = vsetq_lane_s32(GET_NEXT_4BYTES(parms, 1), input0, 1); input1 = vsetq_lane_s32(GET_NEXT_4BYTES(parms, 5), input1, 1); @@ -227,6 +228,7 @@ search_neon_4(const struct rte_acl_ctx *ctx, const uint8_t **data, uint64_t index_array[4]; struct completion cmplt[4]; struct parms parms[4]; + static int32x4_t ZEROVAL; int32x4_t input; acl_set_flow(&flows, cmplt, RTE_DIM(cmplt), data, results, @@ -242,7 +244,7 @@ search_neon_4(const struct rte_acl_ctx *ctx, const uint8_t **data, while (flows.started > 0) { /* Gather 4 bytes of input data for each stream. */ - input = vsetq_lane_s32(GET_NEXT_4BYTES(parms, 0), input, 0); + input = vsetq_lane_s32(GET_NEXT_4BYTES(parms, 0), ZEROVAL, 0); input = vsetq_lane_s32(GET_NEXT_4BYTES(parms, 1), input, 1); input = vsetq_lane_s32(GET_NEXT_4BYTES(parms, 2), input, 2); input = vsetq_lane_s32(GET_NEXT_4BYTES(parms, 3), input, 3); -- 2.21.0