From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C1F7B41C49; Tue, 14 Feb 2023 12:27:41 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A311240EE4; Tue, 14 Feb 2023 12:27:41 +0100 (CET) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by mails.dpdk.org (Postfix) with ESMTP id C9EC040ED9 for ; Tue, 14 Feb 2023 12:27:39 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 4534932008FE; Tue, 14 Feb 2023 06:27:38 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 14 Feb 2023 06:27:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1676374057; x= 1676460457; bh=jTuN1aVqR3Z06iDvpkJqhwWUqRCiUuQo+oJ2cqhED/Q=; b=U KcglqwCRReLcpCxRmJwzQ1nqToyg7NsAWVn7owuU1yj562qaJHSXN2tOMCbybQAo BWhlXbkD6uzYrjgmTGX/YK1cOSoPP0ASuM7qaF84N2ogXPjBZykqQrHmLBn7hyIh pC7LOAwb6OqN68bXMJVponXwnUlTAUpkQ5l4q/FctaMaqXl7f/9Azi/bwTc6LRor 6Jms0fCLEDWSf9pmbhxmpqREdO8dl8NlFasyDq5MNy/6jQof52JJHMcsKyNZ3nSC jiZUl7FbZ9fE/cctC1z4uBJ9o4nLjw9B8uu1c5vWVY2M650PgsKDvgVsJMDQXicU NrYzAnOEoXhMcrwxwTM0w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1676374057; x= 1676460457; bh=jTuN1aVqR3Z06iDvpkJqhwWUqRCiUuQo+oJ2cqhED/Q=; b=P HQdn+fkXF/3BIPYoECaI+6iAwHyehe+nLIzUCj+osVo6A73VoqxoXqAnYhMpIjzh 1qDsXS1QAysSQ4SlHxoHS1aDDU8HXEgxUfqxPZVueoENqMsOqVqHKs+cMYZvZU5L AYwrv1DbAfo8R7D4q6P2glPfe19VjLocXhFlSot7o3aclnQFRX4aMmbhKBuQxNc9 0BoDEHmAr/ecMCmv/RxrhUTvZpSILpJKwIRETWe1LQMZYTd6ouQ+kjSWeeiv950e fhIQKGkw7D60GeACnRpDUqg/M2ahAjcl+yKkGdW9nVsLtQ5EZ9Nkz3nV48BGijQY 7g92+9WX2Kf8h38jpK9xQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudeifedgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtudenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeefhfejleeuvdevtddutdeutdevhfeijeethfffueejhfetuddu vedtkedtieekffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 14 Feb 2023 06:27:36 -0500 (EST) From: Thomas Monjalon To: David Marchand Cc: Morten =?ISO-8859-1?Q?Br=F8rup?= , Bruce Richardson , dev@dpdk.org, Chenbo Xia , Maxime Coquelin , Raslan Darawsheh Subject: Re: [PATCH] disable lock annotation with clang 3.4.2 Date: Tue, 14 Feb 2023 12:27:35 +0100 Message-ID: <5904649.31tnzDBltd@thomas> In-Reply-To: References: <20230213144455.520669-1-david.marchand@redhat.com> <98CBD80474FA8B44BF855DF32C47DC35D87736@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 13/02/2023 17:36, Raslan Darawsheh: > From: Morten Br=F8rup > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > On Mon, Feb 13, 2023 at 03:44:55PM +0100, David Marchand wrote: > > > > Venerable RHEL7 clang 3.4.2 has (at least) two issues with lock > > > > annotations. > > > > > > > > A first one with regards to the attribute position: > > > > ../lib/vhost/vhost.h:518:2: error: GCC does not allow > > > > assert_exclusive_lock attribute in this position on a > > > > function definition [-Werror,-Wgcc-compat] > > > > __rte_assert_exclusive_lock(&vq->access_lock) > > > > ^ > > > > ../lib/eal/include/rte_lock_annotations.h:29:38: note: expanded > > > > from macro '__rte_assert_exclusive_lock' > > > > __attribute__((assert_exclusive_lock(__VA_ARGS__))) > > > > ^ > > > > > > > > This can be worked around by splitting and having the allocation on > > > the > > > > function declaration. > > > > > > > > But on the other hand, clang 3.4.2 does not seem to propagate those > > > > annotations in presence of a __builtin_expect (i.e. unlikely()), li= ke > > > > for example when calling if (unlikely(rte_spinlock_trylock() =3D=3D= 0)). > > > > > > > > Those annotations were only working with clang in any case, so > > > restrict > > > > to clang versions newer than 3.5.0. > > > > > > > > Fixes: 657a98f38940 ("eal: annotate spinlock, rwlock and seqlock") > > > > > > > > Signed-off-by: David Marchand [...] > > > Are we likely to see any issues with this with any other compilers? > > > Should > > > we look to do a built-test in meson to determine feature support rath= er > > > than checking clang versions explicitly? > > > > > > On the plus side, checking clang version like this makes it clear when > > > we > > > can drop the conditional. > >=20 > > I prefer this over auto-detection in meson, for the reason mentioned by > > Bruce. > >=20 > > Furthermore, different compilers may use different syntax in the code, = so it > > is impossible to detect generically; the auto-detection would be per co= mpiler > > anyway. > >=20 > > Acked-by: Morten Br=F8rup > Tested-by: Raslan Darawsheh Applied, thanks.