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.
>
> > +
> > +/**
> > + * 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.
