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 80DE8460D5; Tue, 21 Jan 2025 16:01:09 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 23F7240280; Tue, 21 Jan 2025 16:01:09 +0100 (CET) Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by mails.dpdk.org (Postfix) with ESMTP id 39CB44021F for ; Tue, 21 Jan 2025 16:01:07 +0100 (CET) Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-21644aca3a0so128470885ad.3 for ; Tue, 21 Jan 2025 07:01:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1737471666; x=1738076466; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=5rQYH14MfLfzrlGFoVekEQ8Ie0N2w1T8OG2cIshi5IE=; b=P33xh50zBADSHc2t9iAkgfBLWzHAva/tTUB0n9yG2BFpBfaYMgFNln6V0xltDdE08o ObNrs5/FMjEDUe7OQsQCOAo9sjOBLrrshoSOUowweXG4zhEnvMdBitO7Cw8OZO6zBApS V4uS+VMZmXPx2PN/gAss/e9nPwEXn8p6xO4ZakIOdHVJi/Ys6PJPafgrbzFAZIuKIV1f jHliygL56DGcnNcc4yUMWIitGQdxF5vCg14dqvUxFHlTzNz1G27U4i4vh2NphL72dzsA Q+NLi7glXzcRbIJu06/FU7ToVAUauw1yzOXPjOZrjEOjbY5O+VLmGf88BQicRpqn/Kv4 0ZgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737471666; x=1738076466; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5rQYH14MfLfzrlGFoVekEQ8Ie0N2w1T8OG2cIshi5IE=; b=VI8xm3RWC+hPoPUz0yQbVEZx/hrnlgJcEMf9gfaOAKDF/4p4c6W3z0eVoi0p1SoVAh QFiOHphzoUM7ScQEGkCTXe4XJnxWcG92yhCxvrw7TlYHgoOdNX5OwsZ4YidShTn0GgO3 6/c8jHPx1iLQ0W3NZ0jO3gMYyhQSByQNun/FovroKn5x+KlEFU7LCHOlk9G0oB+3wz91 XEpX8KgnGf3e69QWyZd0FybAPzzMiQ2xpUcpaxlIurXHk8ilOzs7VHDlUrMUzhmFzKxf bQx8UmBpMvhLDm+Mwg1/sZ+TULYyt4RShWpTyyNNFCSnf7BvhCiJXozyt22wrSkY9kTz SkPA== X-Forwarded-Encrypted: i=1; AJvYcCVMYKnrRruHyDOelU31zgfDhNsnX0SDOwHAyYpEdtdIG9lgOAD0/K8tJgVg5ELO2mbHzzs=@dpdk.org X-Gm-Message-State: AOJu0Yz6y2mv5b6kXih0CessAi+yQpnTcBce8c2zMU7I/0pBgRPC0dwr yaUX+RGHPjxpQBndwNkzb5Cg7Q/DFqzxPwahTF5elpGoPJHmhHPzFxssr5Ba4Gw= X-Gm-Gg: ASbGncvNF0Tn06AGb/aBidv5uh3HFq7nnZBW/JapJqyqRwnxGnh6ycN/3+5w2POBgRE Js4ylaJXl1RItZgMpmA4xltKlYXqLX9n15pHrf0zAhMm3DgrxwjanBdHQNTm1HStPpoahTUzyam 5FxKG/LM73MaEmSBbvevVygt7BOvkLjCrDDV5e9Ec/tl9JDBUj85aRS2QiASCN8veOVsPhroNkK 01CGc6MKcCt4nDV7XaozDVRBSWapfUAqiRXxvZtrSAj0mxkrYDT0D9qkeGX9cz/P0ke6Tb5ELuJ yTrFfEJzSWvmtPb5KZzcE1hMw97f1jtHouC2TSWFwLgI5JA= X-Google-Smtp-Source: AGHT+IHSWhXe2o6mh1zMBs3no/IXtSBMvwGVvir247gyk0M2p+qVs039A+B6Beq7CH0resN4FP70UQ== X-Received: by 2002:a05:6a20:728d:b0:1db:eead:c588 with SMTP id adf61e73a8af0-1eb215ec4b9mr28876784637.29.1737471665922; Tue, 21 Jan 2025 07:01:05 -0800 (PST) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-a9bcdcf7c87sm7646512a12.43.2025.01.21.07.01.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jan 2025 07:01:05 -0800 (PST) Date: Tue, 21 Jan 2025 07:01:03 -0800 From: Stephen Hemminger To: Andre Muezerie Cc: Morten =?UTF-8?B?QnLDuHJ1cA==?= , dev@dpdk.org, bruce.richardson@intel.com Subject: Re: [PATCH v15 1/3] eal: add diagnostics macros to make code portable Message-ID: <20250121070103.00a17914@hermes.local> In-Reply-To: <20250121142816.GA30780@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1735263196-2809-1-git-send-email-andremue@linux.microsoft.com> <1737237314-9844-1-git-send-email-andremue@linux.microsoft.com> <1737237314-9844-2-git-send-email-andremue@linux.microsoft.com> <98CBD80474FA8B44BF855DF32C47DC35E9F9CC@smartserver.smartshare.dk> <20250121142816.GA30780@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 On Tue, 21 Jan 2025 06:28:16 -0800 Andre Muezerie wrote: > On Tue, Jan 21, 2025 at 10:53:14AM +0100, Morten Br=C3=B8rup wrote: > > > From: Andre Muezerie [mailto:andremue@linux.microsoft.com] > > > Sent: Saturday, 18 January 2025 22.55 > > >=20 > > > It was a common pattern to have "GCC diagnostic ignored" pragmas > > > sprinkled over the code and only activate these pragmas for certain > > > compilers (gcc and clang). Clang supports GCC's pragma for > > > compatibility with existing source code, so #pragma GCC diagnostic > > > and #pragma clang diagnostic are synonyms for Clang > > > (https://clang.llvm.org/docs/UsersManual.html). > > >=20 > > > Now that effort is being made to make the code compatible with MSVC > > > these expressions would become more complex. It makes sense to hide > > > this complexity behind macros. This makes maintenance easier as these > > > macros are defined in a single place. As a plus the code becomes > > > more readable as well. > > >=20 > > > Signed-off-by: Andre Muezerie > > > --- > > > lib/eal/include/rte_common.h | 46 ++++++++++++++++++++++++++++++++++= ++ > > > 1 file changed, 46 insertions(+) > > >=20 > > > diff --git a/lib/eal/include/rte_common.h > > > b/lib/eal/include/rte_common.h > > > index 40592f71b1..4b87a0a352 100644 > > > --- a/lib/eal/include/rte_common.h > > > +++ b/lib/eal/include/rte_common.h > > > @@ -156,6 +156,52 @@ typedef uint16_t unaligned_uint16_t; > > > #define RTE_DEPRECATED(x) > > > #endif > > >=20 > > > +/** > > > + * Macros to cause the compiler to remember the state of the diagnos= tics as of > > > + * each push, and restore to that point at each pop. > > > + */ > > > +#if !defined(__INTEL_COMPILER) && !defined(RTE_TOOLCHAIN_MSVC) > > > +#define __rte_diagnostic_push _Pragma("GCC diagnostic push") > > > +#define __rte_diagnostic_pop _Pragma("GCC diagnostic pop") > > > +#else > > > +#define __rte_diagnostic_push > > > +#define __rte_diagnostic_pop > > > +#endif > > > + > > > +/** > > > + * Macro to disable compiler warnings about removing a type > > > + * qualifier from the target type. > > > + */ > > > +#if !defined(__INTEL_COMPILER) && !defined(RTE_TOOLCHAIN_MSVC) > > > +#define __rte_diagnostic_ignored_wcast_qual \ > > > + _Pragma("GCC diagnostic ignored \"-Wcast-qual\"") > > > +#else > > > +#define __rte_diagnostic_ignored_wcast_qual > > > +#endif > > > + > > > +/** > > > + * Workaround to discard qualifiers (such as const, volatile, restri= ct) from a pointer, > > > + * without the compiler emitting a warning. > > > + */ > > > +#define RTE_PTR_UNQUAL(X) ((void *)(uintptr_t)(X)) =20 > >=20 > > It seems the C23 typeof_unqual and the built-in pre-C23 __typeof_unqual= __ couldn't be used. > > Was it a generic issue, or only when operating on (the return value of)= functions? =20 >=20 > I experimented with C23 typeof_unqual. It indeed works on gcc, clang and = MSVC, but there are some details: >=20 > a) With gcc the project needs to be compiled with -std=3Dc2x. Many other = warnings show up, unrelated to the scope of this patchset. Some look suspic= ious and should be looked at. An error also showed up, for which I sent out= a small patch. >=20 > b) When using typeof_unqual and passing "-Wcast-qual" to the compiler, a = warning about the qualifier being dropped is emitted. The project currently= uses "-Wcast-qual". Perhaps it shouldn't? >=20 > Due to (a) I decided to not use typeof_unqual for now, but it would be tr= ivial to change the macro to do so in the future. Be careful, C23 changes some things like default initialization of padding = bits. Might break other stuff.