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 D935843AD8; Sun, 18 Feb 2024 16:31:56 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8173F4021D; Sun, 18 Feb 2024 16:31:56 +0100 (CET) Received: from wfout4-smtp.messagingengine.com (wfout4-smtp.messagingengine.com [64.147.123.147]) by mails.dpdk.org (Postfix) with ESMTP id 00609400D5 for ; Sun, 18 Feb 2024 16:31:54 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfout.west.internal (Postfix) with ESMTP id 74A8C1C00089; Sun, 18 Feb 2024 10:31:53 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sun, 18 Feb 2024 10:31:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1708270312; x=1708356712; bh=shnnUyKQbXqofKIZZBvax5NrUW2oa5Kk7UNX2Q9pqlg=; b= kew4zkdeMm4Fohti29p+h/J6DXB6wnUerwzGD66Rz71NT3chgN5i2t1rOUi55bBZ iZU+Xr13+qoW/IumEHrTdzm+T/Yf/xHjqZBmwrm4L+8XC8Xyq7dqiDiZ9RXXyQR9 jR4NjVEY8Mw2omIkcFviC8bppBYICgvBcZUPEyZD4texmk2G815U3Td8X4qoQYuw DqQd+z6iudCptRfp8HJMW+vsuv+lKOuyw8RrTZyYnt9D6tGO2Wbtnu0L+G2VpUFC /hSWtMOc9LFZcCpDFg9Zrsq7vsjnSXy1g8WFMEnzA9Azl4dcvLNZdN2Z+TuEp8Nr Ql9hfnjGsKWctNogN9Uj/g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1708270312; x= 1708356712; bh=shnnUyKQbXqofKIZZBvax5NrUW2oa5Kk7UNX2Q9pqlg=; b=n IYkWBcYNIuUX1GI9j5+oR1sdR0kCfuc9meUT5fODUw1WHMBiDq01L6BYF3kNUm07 uUEk6MDhrXBhCexw+4d4si+OYFonMHvpJzAbva15P5lJXERp3pn4nmQegjbS5ZAR xVh5tQTcKzrde2d7EJOt+CFn/Kal5JdeIAcwry0qzE7bOqHcnQdO/cegfGMKeZlm cc/zukXL/Z/7AFWVkZhB60KPAcZDKj0YhutNvHzZg4mKJMbst5XqL8pJW+ZaHY2e ab+tvfHLtHiPdti2pmsimjzGMF6KXZp1wLgw5EyO8T5fWpuBlwcnn48/OlAvOoTI 4xOUPV0hALDOCBTXac13w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvdeigdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvvefufffkjghfggfgtgesthhqre dttddtudenucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshes mhhonhhjrghlohhnrdhnvghtqeenucggtffrrghtthgvrhhnpeefhfejleeuvdevtddutd eutdevhfeijeethfffueejhfetudduvedtkedtieekffenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrd hnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 18 Feb 2024 10:31:51 -0500 (EST) From: Thomas Monjalon To: Tyler Retzlaff , Mattias =?ISO-8859-1?Q?R=F6nnblom?= Cc: dev@dpdk.org Subject: Re: [PATCH] eal: provide rte attribute macro for GCC attribute Date: Sun, 18 Feb 2024 16:31:50 +0100 Message-ID: <3474620.eGJsNajkDb@thomas> In-Reply-To: <3838403f-af2e-4a2c-b06a-ec4db956d410@lysator.liu.se> References: <1708035618-14090-1-git-send-email-roretzla@linux.microsoft.com> <3556729.8hb0ThOEGa@thomas> <3838403f-af2e-4a2c-b06a-ec4db956d410@lysator.liu.se> 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 18/02/2024 15:51, Mattias R=F6nnblom: > On 2024-02-18 13:24, Thomas Monjalon wrote: > > 15/02/2024 23:20, Tyler Retzlaff: > >> Provide a new macro __rte_attribute(a) that when directly used > >> compiles to empty for MSVC and to __attribute__(a) when using GCC/LLVM. > >> > >> Replace direct use of __attribute__ in __rte_xxx macros where there is > >> existing empty expansion of the macro for MSVC allowing removal of > >> repeated #ifdef RTE_TOOLCHAIN_MSVC per macro to expand empty. > >=20 > > I'm not sure it makes sense. > > I prefer seeing clearly what is empty with MSVC. >=20 > Anything __rte_attribute() is empty on MSVC. You could rename it=20 > __rte_attribute_ignored_by_msvc() for clarity. Yes it would bring more clarity. But I still prefer #ifdef which may work with more compilers. > One could note that on the ignore list are things like "may_alias" and=20 > "packed", so whatever comes out of a MSVC build should not be expected=20 > to actually work. >=20 > Unless I'm missing something, for all the attributes that will have=20 > MSVC-propriety equivalent, the usage pattern would have to change, since= =20 > the syntax is different in incompatible ways. >=20 > Wouldn't it be better to ask the MSVC team to add support GCC=20 > attributes? ICC and LLVM managed, so why not Microsoft. Then you would=20 > solve this issue for all Open Source projects, not only DPDK. We can expect MSVC to improve. That's another reason why I prefer to keep #ifdef to keep track easily.