https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #63 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 2 May 2018, aph at gcc dot gnu.org wrote: > 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. Just sth I noticed. The standard says "it is permitted to inspect the common initial part of any of them" and GCC already allows that. But the testcase in this PR access this common initial part via the actual structure types containing this common initial sequences. GCC has maintained the interpretation of the standard that for struct S *p; an access like p->x is an access of *p with respect to TBAA analysis. But the standard doesn't say you may access both structures containing the initial sequence but it only says you may inspect the common initial part. So if you do int f (struct t1 *p1, struct t2 *p2) { // union U visible here, p1->m and p2->m may alias int *x = &p1->m; int *y = &p2->m; if (*x < 0) *y = -*y; return *x; } then it will work just fine. I guess we all agree that the standards wording isn't 100% clear and that it should be improved. It may of course be that GCCs interpretation that p->x is an access of *p isn't correct. But then I don't need the union clause because if p1->m is an access of 'int' only with respect to TBAA then of course 'int' aliases 'int'.
