From: Stephen Hemminger <stephen@networkplumber.org>
To: Andre Muezerie <andremue@linux.microsoft.com>
Cc: "Morten Brørup" <mb@smartsharesystems.com>,
dev@dpdk.org, bruce.richardson@intel.com
Subject: Re: [PATCH v15 1/3] eal: add diagnostics macros to make code portable
Date: Tue, 21 Jan 2025 07:01:03 -0800 [thread overview]
Message-ID: <20250121070103.00a17914@hermes.local> (raw)
In-Reply-To: <20250121142816.GA30780@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On Tue, 21 Jan 2025 06:28:16 -0800
Andre Muezerie <andremue@linux.microsoft.com> wrote:
> 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 <andremue@linux.microsoft.com>
> > > ---
> > > 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.
Be careful, C23 changes some things like default initialization of padding bits.
Might break other stuff.
next prev parent reply other threads:[~2025-01-21 15:01 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-27 1:33 [PATCH 0/3] " Andre Muezerie
2024-12-27 1:33 ` [PATCH 1/3] lib/eal: " Andre Muezerie
2024-12-27 1:33 ` [PATCH 2/3] drivers/common: " Andre Muezerie
2024-12-27 17:57 ` Stephen Hemminger
2024-12-27 19:43 ` Andre Muezerie
2024-12-27 1:33 ` [PATCH 3/3] drivers/net: " Andre Muezerie
2024-12-28 0:45 ` [PATCH v2 0/3] " Andre Muezerie
2024-12-28 0:45 ` [PATCH v2 1/3] lib/eal: " Andre Muezerie
2024-12-28 0:45 ` [PATCH v2 2/3] drivers/common: " Andre Muezerie
2024-12-28 0:45 ` [PATCH v2 3/3] drivers/net: " Andre Muezerie
2024-12-28 3:18 ` [PATCH v3 0/3] " Andre Muezerie
2024-12-28 3:18 ` [PATCH v3 1/3] lib/eal: " Andre Muezerie
2024-12-28 3:18 ` [PATCH v3 2/3] drivers/common: " Andre Muezerie
2024-12-28 3:18 ` [PATCH v3 3/3] drivers/net: " Andre Muezerie
2024-12-30 15:59 ` [PATCH v4 0/3] " Andre Muezerie
2024-12-30 15:59 ` [PATCH v4 1/3] lib/eal: " Andre Muezerie
2024-12-30 15:59 ` [PATCH v4 2/3] drivers/common: " Andre Muezerie
2024-12-30 15:59 ` [PATCH v4 3/3] drivers/net: " Andre Muezerie
2024-12-30 17:44 ` [PATCH v4 0/3] " Stephen Hemminger
2024-12-31 18:55 ` [PATCH v5 " Andre Muezerie
2024-12-31 18:55 ` [PATCH v5 1/3] lib/eal: " Andre Muezerie
2024-12-31 18:55 ` [PATCH v5 2/3] drivers/common: " Andre Muezerie
2024-12-31 18:55 ` [PATCH v5 3/3] drivers/net: " Andre Muezerie
2024-12-31 20:15 ` [PATCH v6 0/3] " Andre Muezerie
2024-12-31 20:15 ` [PATCH v6 1/3] lib/eal: " Andre Muezerie
2024-12-31 20:15 ` [PATCH v6 2/3] drivers/common: " Andre Muezerie
2024-12-31 20:15 ` [PATCH v6 3/3] drivers/net: " Andre Muezerie
2024-12-31 22:30 ` [PATCH v7 0/3] " Andre Muezerie
2024-12-31 22:30 ` [PATCH v7 1/3] lib/eal: " Andre Muezerie
2024-12-31 22:30 ` [PATCH v7 2/3] drivers/common: " Andre Muezerie
2024-12-31 22:30 ` [PATCH v7 3/3] drivers/net: " Andre Muezerie
2025-01-01 0:48 ` [PATCH v8 0/3] " Andre Muezerie
2025-01-01 0:48 ` [PATCH v8 1/3] lib/eal: " Andre Muezerie
2025-01-01 0:48 ` [PATCH v8 2/3] drivers/common: " Andre Muezerie
2025-01-01 0:48 ` [PATCH v8 3/3] drivers/net: " Andre Muezerie
2025-01-01 3:36 ` [PATCH v9 0/3] " Andre Muezerie
2025-01-01 3:36 ` [PATCH v9 1/3] lib/eal: " Andre Muezerie
2025-01-01 3:36 ` [PATCH v9 2/3] drivers/common: " Andre Muezerie
2025-01-01 3:36 ` [PATCH v9 3/3] drivers/net: " Andre Muezerie
2025-01-03 0:12 ` [PATCH v10 0/3] " Andre Muezerie
2025-01-03 0:12 ` [PATCH v10 1/3] lib/eal: " Andre Muezerie
2025-01-03 0:12 ` [PATCH v10 2/3] drivers/common: " Andre Muezerie
2025-01-03 0:12 ` [PATCH v10 3/3] drivers/net: " Andre Muezerie
2025-01-03 15:36 ` [PATCH v11 0/3] " Andre Muezerie
2025-01-03 15:36 ` [PATCH v11 1/3] lib/eal: " Andre Muezerie
2025-01-03 15:36 ` [PATCH v11 2/3] drivers/common: " Andre Muezerie
2025-01-03 15:36 ` [PATCH v11 3/3] drivers/net: " Andre Muezerie
2025-01-03 19:24 ` [PATCH v11 0/3] " Stephen Hemminger
2025-01-03 21:26 ` Andre Muezerie
2025-01-06 11:00 ` Bruce Richardson
2025-01-08 2:46 ` Andre Muezerie
2025-01-08 9:20 ` Bruce Richardson
2025-01-14 19:20 ` Andre Muezerie
2025-01-15 11:11 ` Bruce Richardson
2025-01-15 4:27 ` [PATCH v12 " Andre Muezerie
2025-01-15 4:27 ` [PATCH v12 1/3] lib/eal: " Andre Muezerie
2025-01-15 9:05 ` Morten Brørup
2025-01-15 4:27 ` [PATCH v12 2/3] drivers/common: " Andre Muezerie
2025-01-15 11:13 ` Bruce Richardson
2025-01-15 4:27 ` [PATCH v12 3/3] drivers/net: " Andre Muezerie
2025-01-16 1:55 ` [PATCH v13 0/3] " Andre Muezerie
2025-01-16 1:55 ` [PATCH v13 1/3] eal: " Andre Muezerie
2025-01-16 1:55 ` [PATCH v13 2/3] drivers/common: " Andre Muezerie
2025-01-16 1:55 ` [PATCH v13 3/3] drivers/net: " Andre Muezerie
2025-01-16 8:57 ` Bruce Richardson
2025-01-18 3:07 ` Andre Muezerie
2025-01-16 9:08 ` Morten Brørup
2025-01-17 3:56 ` Andre Muezerie
2025-01-18 3:05 ` Andre Muezerie
2025-01-16 8:58 ` [PATCH v13 0/3] " Bruce Richardson
2025-01-18 2:46 ` [PATCH v14 " Andre Muezerie
2025-01-18 2:46 ` [PATCH v14 1/3] eal: " Andre Muezerie
2025-01-18 2:46 ` [PATCH v14 2/3] drivers/common: " Andre Muezerie
2025-01-18 2:46 ` [PATCH v14 3/3] drivers/net: " Andre Muezerie
2025-01-18 21:55 ` [PATCH v15 0/3] " Andre Muezerie
2025-01-18 21:55 ` [PATCH v15 1/3] eal: " Andre Muezerie
2025-01-21 9:53 ` Morten Brørup
2025-01-21 14:28 ` Andre Muezerie
2025-01-21 14:41 ` Morten Brørup
2025-01-21 20:17 ` Andre Muezerie
2025-01-21 15:01 ` Stephen Hemminger [this message]
2025-01-18 21:55 ` [PATCH v15 2/3] drivers/common: " Andre Muezerie
2025-01-18 21:55 ` [PATCH v15 3/3] drivers/net: " Andre Muezerie
2025-01-21 22:36 ` [PATCH v16 0/3] " Andre Muezerie
2025-01-21 22:36 ` [PATCH v16 1/3] eal: " Andre Muezerie
2025-01-21 22:36 ` [PATCH v16 2/3] drivers/common: " Andre Muezerie
2025-01-21 22:36 ` [PATCH v16 3/3] drivers/net: " Andre Muezerie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250121070103.00a17914@hermes.local \
--to=stephen@networkplumber.org \
--cc=andremue@linux.microsoft.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=mb@smartsharesystems.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).