From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16892 invoked by alias); 3 Sep 2011 22:54:43 -0000 Received: (qmail 16883 invoked by uid 22791); 3 Sep 2011 22:54:42 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_JS X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 03 Sep 2011 22:54:29 +0000 From: "rafael.espindola at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/50284] possible miscompilation with -fstrict-aliasing Date: Sat, 03 Sep 2011 22:54: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-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rafael.espindola at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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 X-SW-Source: 2011-09/txt/msg00238.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284 --- Comment #4 from Rafael Avila de Espindola 2011-09-03 22:54:10 UTC --- (In reply to comment #3) > struct Value { > struct jsval data; > }; > ... > struct jsval y = t3.array[i]; > struct Value *z = (struct Value*)&y; > if (z->data.tag == 0xFFFFFF85) { > > that's invalid in GCCs reading of 6.5 p7. jsval is a subset of Value's > alias-set > but not the other way around. GCC reads z->data.tag as an access to an > object of type Value which is invalid. So downcast (i.e. casting to a more specialized type) are invalid even if original data type is correct (not that it is in the reduced testcase)? That is really strict :-( > The contorted reasoning is that the pointer conversion invokes undefined > behavior. Definitely an interesting blog post ;) is there any hope that gcc could be made a bit less strict? Either reading the member access as not involving an access to the full object or accepting downcasts (when the original type matches) would work. My preference would be for the second option, as downcasts are fairly common in OO.