https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152
--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 22 Jan 2020, hubicka at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152 > > --- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> --- > Concerning: > > Honza, the type_has_components_p check in > > > > if (compare_type_sizes (TREE_TYPE (ref2), type1) >= 0 > > && (!end_struct_ref1 > > || compare_type_sizes (TREE_TYPE (ref2), > > TREE_TYPE (end_struct_ref1)) >= 0) > > && type_has_components_p (TREE_TYPE (ref2)) > > && (base1_alias_set == ref2_alias_set > > || alias_set_subset_of (base1_alias_set, ref2_alias_set))) > > > > is a compile-time optimization? Because the alias subset check of course > > would trigger here since ref2_alias_set is not the alias-set of > > TREE_TYPE (ref2) but of one of its bases. > > It was not meant as optimization, but to avoid false positives when the base > and ref alias sets intersects but the path can not continue this way. > > I see that here we continue path ending with "long" by path starting by > "union". I guess it is only way to continue from "long", so what about simply > testing > "&& TREE_CODE (TREE_TYPE (base1)) != UNION_TYPE" > (or more carefully we can check if first non-union type after base1 is same as > TREE_TYPE (ref2) Hmm, base1 doesn't have to be a union - we need to check whether there's a union in the path and then skip the type_has_components_p check because there's aliasing with "alternate" paths. So e.f could be a "continuation" from a.u.b.c by means of punning the union a.u (which has members b and e), it actually could not continue as b.d though(!?). > I do not think we need to cut the access path after unions like in your fix. > If that union is wrapped inside struct, one can not continue from type with no > components. Why do we cut the path for VIEW_CONVERT and BIT_FIELD_REF then?
