> I'm wondering if this is the right place to add __rte_may_alias, i.e. if the > scope of the workaround is correct. > > Are the unaligned_uintNN_t types only used in a way where they are affected > by the GCC bug?
All uses in DPDK are for aliasing (casting pointers to access existing memory). There are no cases where these types declare actual data. Therefore adding __rte_may_alias is semantically correct and not too broad. > If not, adding __rte_may_alias to the types themselves may be too broad. > > Does the GCC bug only affect the unaligned_uintNN_t types? > Or does it occur elsewhere or for other types too? Then this workaround only > solves the problem for parts of the code. > The GCC strict-aliasing bug is broader and can occur with other aliasing patterns involving struct initialization. This patch targets the unaligned_uintNN_t types specifically because: 1. They are known to trigger the bug in practice (reproduced in testing) 2. They are explicitly designed for aliasing 3. All existing DPDK usage is for aliasing Added benefits of this approach: 1. Simplifies existing workarounds: We can remove the intermediate packed structs in rte_memcpy.h for x86 and use unaligned_NN_t directly (https://elixir.bootlin.com/dpdk/v25.11/source/lib/eal/x86/include/rte_memcpy.h#L66) 2. Provides safe aliasing primitive: If other code needs to alias types and wants to avoid potential bugs, these unaligned_uintNN_t types are now a correct, safe option > Minor detail: > If the bug only occurs on GCC, not Clang, please make the workaround > GCC-only, using the preprocessor. I've only reproduced the bug on GCC, but __rte_may_alias is semantically correct for these types on all compilers since they're exclusively used for aliasing. The attribute: - Has no negative impact on GCC/Clang (verified on Godbolt - still optimizes correctly: https://godbolt.org/z/Gj9EfqMTn) - Makes the code semantically accurate about its intent - Avoids #ifdef complexity However, if you prefer a GCC-only workaround for minimal change, I'm happy to add the preprocessor conditionals. Please let me know your preference.
