[PATCH v15 1/3] eal: add diagnostics macros to make code portable
Stephen Hemminger
stephen at networkplumber.org
Tue Jan 21 16:01:03 CET 2025
On Tue, 21 Jan 2025 06:28:16 -0800
Andre Muezerie <andremue at linux.microsoft.com> wrote:
> On Tue, Jan 21, 2025 at 10:53:14AM +0100, Morten Brørup wrote:
> > > From: Andre Muezerie [mailto:andremue at 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 at 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.
More information about the dev
mailing list