On Tue, 21 Jan 2025 06:28:16 -0800 Andre Muezerie <andre...@linux.microsoft.com> wrote:
> On Tue, Jan 21, 2025 at 10:53:14AM +0100, Morten Brørup wrote: > > > From: Andre Muezerie [mailto:andre...@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 <andre...@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.
