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 7217B460D2; Tue, 21 Jan 2025 10:53:17 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0574A427C6; Tue, 21 Jan 2025 10:53:17 +0100 (CET) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 182774066E for ; Tue, 21 Jan 2025 10:53:16 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id E47A92027D; Tue, 21 Jan 2025 10:53:14 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [PATCH v15 1/3] eal: add diagnostics macros to make code portable MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jan 2025 10:53:14 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F9CC@smartserver.smartshare.dk> In-Reply-To: <1737237314-9844-2-git-send-email-andremue@linux.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH v15 1/3] eal: add diagnostics macros to make code portable Thread-Index: Adtp862k3SpwnQ6OTXCr7akXPc9oNAB8KTIg 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> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Andre Muezerie" Cc: , , 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 > 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 = 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? > + > +/** > + * 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. > + * > + * @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. E.g.: > + * struct s { > + * uint16_t a; > + * uint8_t b; > + * uint8_t c; > + * uint8_t d; > + * } v; > + * uint16_t * p =3D 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-assum= es-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? Should the use of these workaround macros be disallowed in new code? I.e. should checkpatches check for them?