https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #36 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 25 Jul 2022, rearnsha at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187 > > --- Comment #35 from Richard Earnshaw <rearnsha at gcc dot gnu.org> --- > > There's no union involved here though but a memcpy used in BitCast. > Agreed, but by creating a shared stack slot, the compiler is effectively > creating a union of its own, and I think that needs to be accounted for. > update_alias_info_with_stack_vars handles the cases where we have pointers (at > the gimple level) into a shared stack slot, but doesn't (AFAICT) cater for RTL > lowering creating additional pointers (as it must since all objects on the > stack ultimately have to be addressed). > > So if we create a shared stack slot for objects of different types, why do we > not also create an alias set for the combination of such types, much as we > would do for a union? Note that the only thing we have to do is fix points-to info, the TBAA info should be correct and OK even when objects share location, so there's nothing we can do at RTL expansion time.