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 B0077460D4; Tue, 21 Jan 2025 15:28:19 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7BD96402A4; Tue, 21 Jan 2025 15:28:19 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 70F5140280 for ; Tue, 21 Jan 2025 15:28:17 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1213) id A1ADF205A9E5; Tue, 21 Jan 2025 06:28:16 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com A1ADF205A9E5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1737469696; bh=ArVTFgRaqZm5W/C+IrjXlFuPiAGzIQkgCRbUcWc+ATo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FT0RS6iGYsSP0yy5YtUPVkdPlQor7zIx5B9iaeBbHTlzW1aouhNxqOxlpGRlD9lG5 ouy5gM3AqiPMXUQqkBsMtMvMu9CI5QsjxZrxXHE0UMSFXcmvbWZz+wH/fdvSll5XYz lHnpjfIqJtrfqn/s+EnCK6n/vNJA5VNFuKQuoLxk= Date: Tue, 21 Jan 2025 06:28:16 -0800 From: Andre Muezerie To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: dev@dpdk.org, stephen@networkplumber.org, bruce.richardson@intel.com Subject: Re: [PATCH v15 1/3] eal: add diagnostics macros to make code portable Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F9CC@smartserver.smartshare.dk> User-Agent: Mutt/1.5.21 (2010-09-15) 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, Jan 21, 2025 at 10:53:14AM +0100, Morten Brørup wrote: > > From: Andre Muezerie [mailto:andremue@linux.microsoft.com] > > Sent: Saturday, 18 January 2025 22.55 > > > > 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). > > > > 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. > > > > Signed-off-by: Andre Muezerie > > --- > > lib/eal/include/rte_common.h | 46 ++++++++++++++++++++++++++++++++++++ > > 1 file changed, 46 insertions(+) > > > > 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 > > > > +/** > > + * Macros to cause the compiler to remember the state of the diagnostics 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, restrict) from a pointer, > > + * without the compiler emitting a warning. > > + */ > > +#define RTE_PTR_UNQUAL(X) ((void *)(uintptr_t)(X)) > > 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? I experimented with C23 typeof_unqual. It indeed works on gcc, clang and MSVC, but there are some details: a) With gcc the project needs to be compiled with -std=c2x. Many other warnings show up, unrelated to the scope of this patchset. Some look suspicious and should be looked at. An error also showed up, for which I sent out a small patch. 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? Due to (a) I decided to not use typeof_unqual for now, but it would be trivial to change the macro to do so in the future. > > > + > > +/** > > + * Workaround to discard qualifiers (such as const, volatile, restrict) from a pointer > > + * and cast it to a specific type, without the compiler emitting a warning. > > Propose new description with emphasis on casting rather than discarding qualifiers: > > Workaround to cast a pointer to a specific type, > without the compiler emitting a warning about discarding qualifiers. > I'll update this. > > + * > > + * @warning > > + * Although this macro can be abused for casting a pointer to point to a different type, > > + * alignment may be incorrect when casting to point to a larger type. E.g.: > > This macro is now meant for abuse, so propose softening the warning: > > When casting a pointer to point to a larger type, > the resulting pointer may be misaligned, > which causes undefined behavior. I'll update this. > E.g.: > > > + * struct s { > > + * uint16_t a; > > + * uint8_t b; > > + * uint8_t c; > > + * uint8_t d; > > + * } v; > > + * uint16_t * p = RTE_CAST_PTR(uint16_t *, &v.c); // "p" is not 16 bit aligned! > > + */ > > +#define RTE_CAST_PTR(type, ptr) ((type)(uintptr_t)(ptr)) > > I am somewhat concerned about these macros... > > There's a good reason why MSVC doesn't allow casting to discard qualifiers or changing the type like this. > > If in doubt, read this: > https://www.trust-in-soft.com/resources/blogs/2020-04-06-gcc-always-assumes-aligned-pointer-accesses > > We need these workarounds because DPDK currently contains code with formally "undefined behavior". > And instead of fixing the root causes, we choose the pragmatic solution and introduce workarounds to allow it. > > Would it be possible for the RTE_CAST_PTR macro to check if the casted-to pointer changes from a smaller type to a larger type, and warn/fail if it does? I'll think about it. > > Should the use of these workaround macros be disallowed in new code? > I.e. should checkpatches check for them? We can certainly add a check to checkpatches.