https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #56 from Davin McCall <davmac at davmac dot org> --- (In reply to James Kuyper Jr. from comment #55) > The problem is, you're using a statement that the access must occur via a > union, with the implication that the code in question does not access the > member through the union. If "via a union" allows that at some point that the address of a union member was taken and that pointer is then dereferenced, and type punning via a union is allowed (as is implied by another footnote in the same section), then: 1) all type-based alias analysis is effectively impossible 2) the "special guarantee" clause is completely redundant, and the requirement for visibility of the union declaration doubly so. The real problem is that "it is permitted to inspect" doesn't say how one should perform an "inspection" nor what the result should be. You want it to mean "access (read) the structure member in the normal way and have its value match that of the corresponding structure member from the common initial sequence of the active member". But the "special guarantee" grants a permission, which is most easily read as not doing anything other than specifying that a certain action (reading a struct member) doesn't have undefined behaviour in certain circumstances. It's not even actually explicated that the value read should match that of the corresponding common-initial-sequence member of the struct object that is the active member of the union object in question; in thinking that it should be, we're already making the assumption that this clause is intended to permit a certain case of type-punning. But, as I noted above, if type-punning is generally allowed, and if accessing via the union "immediately" has the same semantics as taking the address of the union member and accessing via the resulting pointer - then the clause isn't necessary anyway, except to mandate that the common-initial-sequence layout is identical between distinct structs which are punned in this way, and in that case what is the point of requiring that the union declaration be visible? (Unless you want to argue that the point is to mandate the common initial sequence layout is necessarily identical only if the union declaration is visible; however, since the layout necessarily applies to the rest of the program also, why should it matter where the union declaration is?). So for your interpretation I believe you need that either: 1) type punning via a union is not normally permissible, despite the footnote claiming it is, and 2) a lot of production code is broken. or 1) type punning via a union is permissible and the "special guarantee" clause serves only to enforce common layout of structs, and the union declaration amendment is not sensible, and 2) TBAA is impossible and most current compilers are broken. or 1) type punning via a union is permissible, but the semantics of accessing a member of the union "immediately" do differ to those of taking the address of the member and later dereferencing it, despite the fact that the text does not explicate this, and 2) the "special guarantee" clause changes the semantics of "indirect" union member access to match those of "direct" member access, in specified cases, despite that the present wording only dances around this topic without ever touching it. > The standard explicitly says, referring to the same example mentioned in DR > 257, that the second code fragment is not valid, but only "because the union > type is not visible within function f", implying that it would be valid if > the declaration of the union type were moved so that it would be visible > inside f(). If it were so moved, it would be essentially equivalent to the > code which was the original defect report. While examples are non-normative, > that example implies that the visibility clause was intended to actually > serve a purpose (and it seems obvious to me that it actually does so). I'm not arguing that N685 wasn't intended to do exactly as you suggest, but I'm not sure the wording pre-amendment really suffered from the problem that N685 supposedly addresses, and I certainly don't agree that the amended wording is clear in meaning.
