Re: [PATCH v14 1/2] eal: add __rte_may_alias to unaligned typedefs

Scott Mitchell
2026-01-12T15:00:43Z

> 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.