From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26154 invoked by alias); 31 May 2013 08:48:50 -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 26098 invoked by uid 48); 31 May 2013 08:48:47 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/57359] wrong code for union access at -O3 on x86_64-linux Date: Fri, 31 May 2013 08:48:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: WAITING 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: bug_status cf_reconfirmed_on cc resolution everconfirmed 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: 2013-05/txt/msg02139.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |WAITING Last reconfirmed| |2013-05-31 CC| |rguenth at gcc dot gnu.org Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #7 from Richard Biener --- (In reply to Dara Hazeghi from comment #5) > Sorry to ask again on this, but after re-reading, I'm not sure I understand > the type-punning argument here: > > **ppll = ll; // write to u.ll > *k = 0; // write to u.i > > j = *ppa; // u not touched > ia[0][0] = *j; // u not touched > > printf("%d\n", u.i); // read from u.i > > > From what I can tell, this is in fact reading the last member written to (so > not falling under the unspecified behaviors listed in annex J / 6.2.6.1). > Perhaps there is an additional restriction I am missing? If the above is what really happens (the testcase is quite obfuscated ;)) then the testcase is valid. Can you try to un-obfuscate it somewhat?