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 1AA1643B57; Tue, 20 Feb 2024 19:27:16 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A4AB8402A7; Tue, 20 Feb 2024 19:27:15 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 740B540289 for ; Tue, 20 Feb 2024 19:27:14 +0100 (CET) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 9B08E5C0093; Tue, 20 Feb 2024 13:27:13 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 20 Feb 2024 13:27:13 -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=1708453633; x=1708540033; bh=KtpAOOcXKMCGx4NWvv+v1H8vnfmsRi6oeM4t3APZyH8=; b= o/Fq38hxtWee43vtnkRssu6rXlAZjc1z3gpTFnZ9QM3CqMRkQuzlbQuVi2DN2Shz ClSu/M8+RJCuRgN7e6vgmY+zNyIaMbO46kYS1TsRxKT2SVnJXCZ3XksYBDiO70cH HAKvVOsk6ELl8aL5mnyawmP72qZz2jEwTpg6x3Vy/VVR4aEN+oPNE6dA/zVEc3HB 0rRBK0wXetogCGePp7p529CMyHnZtXyjZbqXNVw6lQsHc/XMfojuwD6SQR2tlIJB GrE+LyUjAACx3m0hcSe7EAgSb8tgaVP+/Kq//H1yhzFi62LvRHHWY5Oi5qsbWVRX sQkog0YBAPgX58TwWly4kw== 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=1708453633; x= 1708540033; bh=KtpAOOcXKMCGx4NWvv+v1H8vnfmsRi6oeM4t3APZyH8=; b=p 2orcNvsknoogfKqs3Lqcq5mcHnaSJCky9hbKbVm2CZYkOIAl9bUC82xcgbDojExH 1up7DwJ5Hdahaauqh96JoR2uOK+va3Our32Jtg19f/0ZdzJNy1X60vovit1JaPoR guL5NpD5WxKQvRCNfyDuQHVDkG2mqYz39bU8Hx5Sw3ILcF/blwDJFYNRiQGFfkCU LUvuIGhMqzseB2LwJxs0tv6xmQt4I9j1/IDzZa7uMSsXMJ88ctkli7AVNygblywt vBf8mNytOBv8fMs3pGiGxo19GWKQqiDZ9imDgwjxJAmN8zrWMxXLKUm62hKRNfss POBFvDSeTralWKsd47VmQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedtgdduudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvfevufffkfgjfhgggfgtsehtqh ertddttddunecuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceothhhohhmrghs sehmohhnjhgrlhhonhdrnhgvtheqnecuggftrfgrthhtvghrnhepfefhjeeluedvvedtud dtuedtvefhieejtefhffeujefhteduudevtdektdeikeffnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonh drnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 20 Feb 2024 13:27:12 -0500 (EST) From: Thomas Monjalon To: Tyler Retzlaff Cc: Mattias =?ISO-8859-1?Q?R=F6nnblom?= , dev@dpdk.org Subject: Re: [PATCH] eal: provide rte attribute macro for GCC attribute Date: Tue, 20 Feb 2024 19:27:10 +0100 Message-ID: <3479090.GKX7oQKdZx@thomas> In-Reply-To: <20240220180629.GB19214@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1708035618-14090-1-git-send-email-roretzla@linux.microsoft.com> <3474620.eGJsNajkDb@thomas> <20240220180629.GB19214@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> 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 20/02/2024 19:06, Tyler Retzlaff: > On Sun, Feb 18, 2024 at 04:31:50PM +0100, Thomas Monjalon wrote: > > 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 ther= e 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. > >=20 > > Yes it would bring more clarity. > > But I still prefer #ifdef which may work with more compilers. > >=20 > > > One could note that on the ignore list are things like "may_alias" an= d=20 > > > "packed", so whatever comes out of a MSVC build should not be expecte= d=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, si= nce=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 woul= d=20 > > > solve this issue for all Open Source projects, not only DPDK. > >=20 > > We can expect MSVC to improve. > > That's another reason why I prefer to keep #ifdef to keep track easily. >=20 > MSVC is committed to provide functionality where something simply cannot > be done at all with their toolset and standard C. That makes sense. > They will not make changes to their toolset for functionality they alread= y have. So you mean there is already a way to insert zero-size markers in a struct?