From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 84C95A058A; Fri, 17 Apr 2020 17:43:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 696FC1E97A; Fri, 17 Apr 2020 17:43:56 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id 1BED71E976 for ; Fri, 17 Apr 2020 17:43:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587138234; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qBLI6JBtn1dxYvsWj83CpANHznWrM4nmct1Qnzt5izk=; b=QgG1d+Y4KOZscMDHjo0bh8w3T6FQXkSC2t+LnTzzx75KWnpm+s9LJWmhwhoNSt9LXE9oh7 +tYVsOHm0QZcT4Dvs8pxtCCDBF+2JZHpAMAiA/2CuwwOhasExUaP54tFWA6sdgjv+F/vuc FcJOWs3rx5WDwBmy/nS37rUCq4koSEQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-276-GQy30Kx8Ppy3pJxWFoMGgQ-1; Fri, 17 Apr 2020 11:43:50 -0400 X-MC-Unique: GQy30Kx8Ppy3pJxWFoMGgQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6B40A8017F6; Fri, 17 Apr 2020 15:43:47 +0000 (UTC) Received: from rh.redhat.com (unknown [10.33.36.201]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3064F5D9CA; Fri, 17 Apr 2020 15:43:42 +0000 (UTC) From: Kevin Traynor To: dev@dpdk.org, thomas@monjalon.net, bruce.richardson@intel.com, Gavin.Hu@arm.com, konstantin.ananyev@intel.com Cc: ravi1.kumar@amd.com, g.singh@nxp.com, hemant.agrawal@nxp.com, akhil.goyal@nxp.com, johndale@cisco.com, hyonkim@cisco.com, jingjing.wu@intel.com, wenzhuo.lu@intel.com, rmody@marvell.com, shshaikh@marvell.com, matan@mellanox.com, shahafs@mellanox.com, declan.doherty@intel.com, cristian.dumitrescu@intel.com, Kevin Traynor Date: Fri, 17 Apr 2020 16:43:35 +0100 Message-Id: <20200417154335.14147-1-ktraynor@redhat.com> In-Reply-To: <20200416184549.10747-1-ktraynor@redhat.com> References: <20200416184549.10747-1-ktraynor@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [dpdk-dev] [PATCH v3] x86/eal: gcc 10 ignore stringop-overflow warnings 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" stringop-overflow warns when it sees a possible overflow in a string operation. In the rte_memcpy functions different branches are taken depending on the size. stringop-overflow is raised for the branches in the function where it sees the static size of the src could be overflowed. However, in reality a correct size argument and in some cases dynamic allocation would ensure that this does not happen. For example, in the case below for key, the correct path will be chosen in rte_memcpy_generic at runtime based on the size argument but as some paths in the function could lead to a cast to 32 bytes a warning is raised. In function =E2=80=98_mm256_storeu_si256=E2=80=99, inlined from =E2=80=98rte_memcpy_generic=E2=80=99 at ../lib/librte_eal/common/include/arch/x86/rte_memcpy.h:315:2, inlined from =E2=80=98iavf_configure_rss_key=E2=80=99 at ../lib/librte_eal/common/include/arch/x86/rte_memcpy.h:869:10: /usr/lib/gcc/x86_64-redhat-linux/10/include/avxintrin.h:928:8: warning: writing 32 bytes into a region of size 1 [-Wstringop-overflow=3D] 928 | *__P =3D __A; | ~~~~~^~~~~ In file included from ../drivers/net/iavf/../../common/iavf/iavf_prototype.h:10, from ../drivers/net/iavf/iavf.h:9, from ../drivers/net/iavf/iavf_vchnl.c:22: ../drivers/net/iavf/iavf_vchnl.c: In function =E2=80=98iavf_configure_rss_key=E2=80=99: ../drivers/net/iavf/../../common/iavf/virtchnl.h:508:5: note: at offset 0 to object =E2=80=98key=E2=80=99 with size 1 declared here 508 | u8 key[1]; /* RSS hash key, packed bytes */ | ^~~ Ignore the stringop-overflow warnings for rte_memcpy.h functions. Bugzilla ID: 394 Bugzilla ID: 421 Signed-off-by: Kevin Traynor --- v3: Add push/pop to not leak the ignore warning v2: Change from a global disable to just disabling for x86/rte_memcpy.h --- lib/librte_eal/x86/include/rte_memcpy.h | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/lib/librte_eal/x86/include/rte_memcpy.h b/lib/librte_eal/x86/i= nclude/rte_memcpy.h index ba44c4a32..9c67232df 100644 --- a/lib/librte_eal/x86/include/rte_memcpy.h +++ b/lib/librte_eal/x86/include/rte_memcpy.h @@ -23,4 +23,9 @@ extern "C" { #endif =20 +#if defined(RTE_TOOLCHAIN_GCC) && (GCC_VERSION >=3D 100000) +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wstringop-overflow" +#endif + /** * Copy bytes from one location to another. The locations must not overlap= . @@ -870,4 +875,8 @@ rte_memcpy(void *dst, const void *src, size_t n) } =20 +#if defined(RTE_TOOLCHAIN_GCC) && (GCC_VERSION >=3D 100000) +#pragma GCC diagnostic pop +#endif + #ifdef __cplusplus } --=20 2.21.1