https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #62 from Andrew Haley <aph at gcc dot gnu.org> --- Just a bit of clarification: (In reply to James Kuyper Jr. from comment #59) > > > 1) all type-based alias analysis is effectively impossible > > Alias analysis is only affected by the special guarantee if > a) the types involved are both struct types > b) both struct types are members of the same union > c) the struct types share a common initial sequence OK to all of those. > d) the code in question inspects the value of one of the members of the > common initial sequence. While this is a reasonable inference from what the text of the standard says, type-based alias analysis, by definition, does not pay any attention to what any piece of code does. The analysis is purely type-based: that is to say, it only uses the types, and the only question it answers is "Do these types alias?" > e) a completed declaration of the union type that they are members > of is visible at the point in the code where the inspection occurrs. As explained elsewhere, TBAA doesn't use visibility as a criterion. > It seems to me that the overwhelming majority of cases will fail to > meet at least one of those requirements, so type-based alias > analysis is still possible, it's just made more complicated by the > need to check for those things. That's not quite right, as explained above. If you use information other than types in alias analysis, it's no longer TBAA. It is a fundamental principle of TBAA that the result of an aliasing query never changes for any pair of types. We are extremely unlikely to redesign a big part of the optimizer for this dusty corner case.
