https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106389
--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> --- I agree with Richi that this is not modref bug. It merely exposes the fact that we intentionally ignore this rule. For single compilation unit this rule is already problematic since one can not determine alias sets incrementally. If struct A and struct B share same initial segment one needs to delay any TBAA decisions about them until the end of translation unit when one knows if union of A and B exists and then one needs to pesimize the optimization. However standard does not seem to require union to be in the given translation unit (think of comdat inlines where aliasing of A/B happens in one translation unit and function is called from other). Moreover with LTO we do not stream types not needed for a given partition of program and the union may thus be lost on the way. So I do not see how to implement this correctly short of 1) giving up on base alias set disambiguations 2) delaying all alias set constructions after finalizing all user defined types, look for all possible initial segments and hack alias oracle to know about this. Even this is hard since we currently do disambiguations based on pairs base_set, ref_set without knowing the offset of ref_set inside base_set so given two pairs base_set1, ref_set1 base_set2, ref_set2 we would not be able to disambiguate accesses with same ref sets that occurs after the common initial part of the type. So indeed I would prefer this to stay undefined and require may_alias attribute in the user code...
