From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34777 invoked by alias); 28 Apr 2015 17:08:41 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 34497 invoked by uid 55); 28 Apr 2015 17:08:36 -0000 From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/65892] gcc fails to implement N685 aliasing of union members Date: Tue, 28 Apr 2015 17:08:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: alias X-Bugzilla-Severity: normal X-Bugzilla-Who: joseph at codesourcery dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-04/txt/msg02433.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #9 from joseph at codesourcery dot com --- The rule certainly has nothing to do with whether the struct types are defined inside the union definition, or defined outside and then used inside via a tag or typedef. The "it is permitted" wording is poorly defined, and the C99 changes confused this through failing to realise how it's poorly defined. In C90, the paragraph starts "With one exception, if a member of a union object is accessed after a value has been stored in a different member of the object, the behavior is implementation-defined.[41] One special guarantee is made ... it is permitted ...". This reads to me like "it is permitted" was intended as an exception to the general rule of behavior being implementation-defined (that is, it was defining one case of type punning, which was more generally defined non-normatively in the footnote added in C99 TC3). The difficulty with "it is permitted" is there are any number of cases where other wording indicates something is not permitted that it could be interpreted as overriding - just saying "it is permitted" fails to say which are or are not overridden. (As a C11 example, something might not be permitted because it's a data race, for example, but accessing a common initial sequence can hardly be intended to override the normal rules about data races.) So the authors of N685 read "it is permitted" as relating not to the previous sentence in the same paragraph about accessing different union members, but as relating to completely separate rules about aliasing. The visible union rule was then inserted for C99, thereby serving to confuse things further by supporting the suggestion that "it is permitted" relates to aliasing. DR#236 then considered a different case of aliasing through pointers to union members. However, the response never decided the question of whether the accesses must visibly be through the union, or whether it's sufficient for the declaration of the union to be visible. Basing things on whether a union is visible in the translation unit is clearly a bad rule because of action-at-a-distance effects (the visible union might be in a header included for some completely unrelated purpose, but would still inhibit optimization). (Note that the exact example given in this bug is invalid as the union has active member s1, but is modified via member s2; you can only "inspect" common members of non-active union members, not modify them. But presumably using .s2 in the initializer would still show the issue.) Thus, "it is permitted" needs reworking to describe what it's an exception to. To the extent that it's an exception to aliasing rules, I think that should only be where the union is actually used for the accesses in question (in which case no exception is actually needed beyond defining the layout requirements and making the type punning rules normative), and DR#236 should be clarified accordingly.