public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/50284] possible miscompilation with -fstrict-aliasing Date: Sun, 04 Sep 2011 08:58:00 -0000 [thread overview] Message-ID: <bug-50284-4-0YZOP5uoNl@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-50284-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284 Richard Guenther <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID --- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-09-04 08:57:35 UTC --- (In reply to comment #4) > (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 :-( No, if there is an object of dynamic type Value at &y then the code is valid. But you've stored to *&y via an lvalue of type jsval and are reading from it via an lvalue of type Value. > > 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. Well, if we allow this case then we can drop any advanced TBAA we do completely. This restriction is really fundamental to TBAA based optimizations. Otherwise consider int i; struct X { int k; .... }; int foo(struct X *p) { i = 0; p->k = 1; return i; } and we couldn't be sure that p->k is not accessing i and thus not optimize the above to return 0. That would be very bad. You have -fno-strict-aliasing to "save" you. Your better testcase doesn't change anything - you've just changed the type of an unrelated object.
prev parent reply other threads:[~2011-09-04 8:58 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-09-03 18:50 [Bug c/50284] New: " rafael.espindola at gmail dot com 2011-09-03 18:54 ` [Bug c/50284] " rafael.espindola at gmail dot com 2011-09-03 19:08 ` rafael.espindola at gmail dot com 2011-09-03 20:53 ` rguenth at gcc dot gnu.org 2011-09-03 22:54 ` rafael.espindola at gmail dot com 2011-09-04 3:50 ` rafael.espindola at gmail dot com 2011-09-04 8:58 ` rguenth at gcc dot gnu.org [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-50284-4-0YZOP5uoNl@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).