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 22B21A058A; Fri, 17 Apr 2020 12:13:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E9DEA1D6E2; Fri, 17 Apr 2020 12:13:34 +0200 (CEST) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id 7B8791D6D0 for ; Fri, 17 Apr 2020 12:13:33 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id C75C6580459; Fri, 17 Apr 2020 06:13:32 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 17 Apr 2020 06:13:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=kp7Kq+0q6WxhciGi4pIqeOyPXgMnIODM3rzVu8Ei8no=; b=h/nr6yippHPR AW+/pk8kYAPpQpMfYN/dY923N3WXzwq1eZbjmhN4sVFbEpOvm+5JC38WAB/NTi/W gXb7eYaE6OByB52NVszH5F5RgoBqh3ZpEBZjRLIMerbZY2NnUzHeKO2lO5Qcoxt0 WJHvyTNKP8j310UNsPgQjdFZlpw1in4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=kp7Kq+0q6WxhciGi4pIqeOyPXgMnIODM3rzVu8Ei8 no=; b=YNerR8j/4ZD7DS0LNiJFEXaKvGLXKYzt84PVF8mb7iRPpWk7mYOuUCg2s sa7k5SJHgcN+4ltr3ByX0agU4ZCxGtIbAQcJ9rf2p4nf7InFyKW5sOR7yyo58haB w/MsV9KdoHsLWZgz/lBZ2b1Lw8/VlQHrzb+a+bPzT/Qdvslmy9QJXG8LqD+INX4I UrM1XdeK76D9IVwsmkha8SWaMTqndzrH2K492eS7fwFI7hHeEBRHVGWNNOyMeE6n PwQV0ezHZx7PFf2CNNjoYMnMpekVJqFk/QHshCW+dkWuMEjOSZAWEuOpb6B0tao0 Jg+mleywTTn9jO17yYvYTOVffDoeQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfeejgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 3723C3060062; Fri, 17 Apr 2020 06:13:30 -0400 (EDT) From: Thomas Monjalon To: Kevin Traynor , Bruce Richardson Cc: dev@dpdk.org, Gavin.Hu@arm.com, 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, konstantin.ananyev@intel.com, zhihong.wang@intel.com Date: Fri, 17 Apr 2020 12:13:29 +0200 Message-ID: <3643335.9fHWaBTJ5E@thomas> In-Reply-To: <20200417093358.GB1701@bricha3-MOBL.ger.corp.intel.com> References: <20200407162755.6802-1-ktraynor@redhat.com> <20200416184549.10747-1-ktraynor@redhat.com> <20200417093358.GB1701@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2] 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" 17/04/2020 11:33, Bruce Richardson: > On Thu, Apr 16, 2020 at 07:45:49PM +0100, Kevin Traynor wrote: > > stringop-overflow warns when it sees a possible overflow > > in a string operation. > >=20 > > 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. > >=20 > > However, in reality a correct size argument and in some cases > > dynamic allocation would ensure that this does not happen. > >=20 > > 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. > >=20 > > 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: > >=20 > > /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: > >=20 > > ../drivers/net/iavf/iavf_vchnl.c: > > In function =E2=80=98iavf_configure_rss_key=E2=80=99: > >=20 > > ../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 */ > > | ^~~ > >=20 > > Ignore the stringop-overflow warnings for rte_memcpy.h functions. > >=20 > > Bugzilla ID: 394 > > Bugzilla ID: 421 > >=20 > > Signed-off-by: Kevin Traynor [...] > > --- a/lib/librte_eal/x86/include/rte_memcpy.h > > +++ b/lib/librte_eal/x86/include/rte_memcpy.h > > +#if defined(RTE_TOOLCHAIN_GCC) && (GCC_VERSION >=3D 100000) > > +#pragma GCC diagnostic ignored "-Wstringop-overflow" > > +#endif >=20 > Does this permanently need to be disabled for all compilation units > including rte_memcpy.h, or can it be used with a push/pop set of pragmas = to > only disable for the required functions? Even better, isn't there a solution in memcpy code?