> From: David Marchand [mailto:[email protected]] > Sent: Monday, 16 February 2026 15.29 > > Hello Scott, Andre, Tyler, > > On Mon, 2 Feb 2026 at 05:48, <[email protected]> wrote: > > > > From: Scott Mitchell <[email protected]> > > > > Add __rte_may_alias attribute to unaligned_uint{16,32,64}_t typedefs > > to prevent GCC strict-aliasing optimization bugs. GCC has a bug where > > it incorrectly elides struct initialization when strict aliasing is > > enabled, causing reads from uninitialized memory. > > > > Add __rte_aligned(1) attribute to unaligned_uint{16,32,64}_t typedefs > > which allows for safe access at any alignment. Without this, > accessing > > a uint16_t at an odd address is undefined behavior. Without this > > UBSan detects `UndefinedBehaviorSanitizer: undefined-behavior`. > > > > Fixes: 7621d6a8d0bd ("eal: add and use unaligned integer types") > > Cc: [email protected] > > > > Signed-off-by: Scott Mitchell <[email protected]> > > [snip] > > > diff --git a/lib/eal/include/rte_common.h > b/lib/eal/include/rte_common.h > > index 573bf4f2ce..7b36966019 100644 > > --- a/lib/eal/include/rte_common.h > > +++ b/lib/eal/include/rte_common.h > > @@ -121,16 +121,42 @@ extern "C" { > > #define __rte_aligned(a) __attribute__((__aligned__(a))) > > #endif > > > > -#ifdef RTE_ARCH_STRICT_ALIGN > > -typedef uint64_t unaligned_uint64_t __rte_aligned(1); > > -typedef uint32_t unaligned_uint32_t __rte_aligned(1); > > -typedef uint16_t unaligned_uint16_t __rte_aligned(1); > > +/** > > + * Macro to mark a type that is not subject to type-based aliasing > rules > > + */ > > +#ifdef RTE_TOOLCHAIN_MSVC > > +#define __rte_may_alias > > #else > > -typedef uint64_t unaligned_uint64_t; > > -typedef uint32_t unaligned_uint32_t; > > -typedef uint16_t unaligned_uint16_t; > > +#define __rte_may_alias __attribute__((__may_alias__)) > > #endif > > > > +/* Unaligned types implementation notes: > > + * __rte_aligned(1) - Reduces alignment requirement to 1 byte, > allowing > > + * these types to safely access memory at any > address. > > + * Without this, accessing a uint16_t at an odd > address > > + * is undefined behavior (even on x86 where > hardware > > + * handles it). > > + * > > + * __rte_may_alias - Prevents strict-aliasing optimization bugs > where > > + * compilers may incorrectly elide memory > operations > > + * when casting between pointer types. > > + */ > > + > > +/** > > + * Type for safe unaligned u64 access. > > + */ > > +typedef __rte_may_alias __rte_aligned(1) uint64_t > unaligned_uint64_t; > > + > > +/** > > + * Type for safe unaligned u32 access. > > + */ > > +typedef __rte_may_alias __rte_aligned(1) uint32_t > unaligned_uint32_t; > > + > > +/** > > + * Type for safe unaligned u16 access. > > + */ > > +typedef __rte_may_alias __rte_aligned(1) uint16_t > unaligned_uint16_t; > > + > > /** > > * @deprecated > > * @see __rte_packed_begin > > @@ -159,15 +185,6 @@ typedef uint16_t unaligned_uint16_t; > > #define __rte_packed_end __attribute__((__packed__)) > > #endif > > > > -/** > > - * Macro to mark a type that is not subject to type-based aliasing > rules > > - */ > > -#ifdef RTE_TOOLCHAIN_MSVC > > -#define __rte_may_alias > > -#else > > -#define __rte_may_alias __attribute__((__may_alias__)) > > -#endif > > - > > /******* Macro to mark functions and fields scheduled for removal > *****/ > > #ifdef RTE_TOOLCHAIN_MSVC > > #define __rte_deprecated > > This change raises a warning in checkpatch. > https://mails.dpdk.org/archives/test-report/2026-February/955237.html > > IIRC, we added this check for MSVC support, making sure no > __rte_aligned() would be added in unsupported locations.
It looks like MSVC can use alignment for type definitions too: https://learn.microsoft.com/en-us/cpp/cpp/align-cpp?view=msvc-170#vclrf_declspecaligntypedef It is applied on a structure, though, so may not be viable for scalar types. IDK. But it looks like MSVC can only increase alignment: https://learn.microsoft.com/en-us/cpp/cpp/align-cpp?view=msvc-170#:~:text=__declspec(align(%23))%20can%20only%20increase%20alignment%20restrictions. So packing may be needed too. > > @Microsoft guys, do you have a suggestion? > > > -- > David Marchand
