public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "gcc2eran at tromer dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted Date: Sun, 03 Jul 2005 12:12:00 -0000 [thread overview] Message-ID: <20050703121248.16557.qmail@sourceware.org> (raw) In-Reply-To: <20050514140942.21568.rguenth@gcc.gnu.org> ------- Additional Comments From gcc2eran at tromer dot org 2005-07-03 12:12 ------- To make it easier to evaluate my claim, here are all messages in the thread linked from comment 1 that seemingly contradicy comment 9: Nathan Sidwell: http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html Dale Johannesen: http://gcc.gnu.org/ml/gcc/2005-05/msg00090.html Andrew Haley: http://gcc.gnu.org/ml/gcc/2005-05/msg00144.html All of these, I am sorry to say, misinterpret the standard since they misconstrue the meaning of the term "object" in the C type system. They assume that the object's type is determined by the way it was created (which is indeed the usual meaning in other languages), whereas the standard quite clearly defines an object's type to be determined by the lvalue referencing it. To give one example of this confusion, here is what Dale Johannesen said: "the standard consistently talks about the type of the object, not the type of the lvalue, when describing volatile." And here is what N1124 [6.3.2.1/1] says: "When an object is said to have a particular type, the type is specified by the lvalue used to designate the object." See my point? I admit to earning my language lawyer diploma on languages other than C, but the evidence in comment 9 seems very firm to me. Does anyone see any flaw in it? If not, then shouldn't this bug be reopened? Hey, we should be *happy* that we found a standard-compliance excluse to fix the code-breaking regression and make those casts work like everybody wanted! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21568
next prev parent reply other threads:[~2005-07-03 12:12 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-05-14 14:09 [Bug tree-optimization/21568] New: [3.4 " rguenth at gcc dot gnu dot org 2005-05-14 16:32 ` [Bug tree-optimization/21568] [4.0/4.1 " pinskia at gcc dot gnu dot org 2005-05-21 13:50 ` rguenth at gcc dot gnu dot org 2005-05-21 17:31 ` schlie at comcast dot net 2005-05-21 18:10 ` debian-gcc at lists dot debian dot org 2005-05-21 20:48 ` schlie at comcast dot net 2005-07-02 16:48 ` pinskia at gcc dot gnu dot org 2005-07-03 4:55 ` gcc2eran at tromer dot org 2005-07-03 5:52 ` pinskia at gcc dot gnu dot org 2005-07-03 6:50 ` gcc2eran at tromer dot org 2005-07-03 12:12 ` gcc2eran at tromer dot org [this message] 2005-07-03 17:33 ` schlie at comcast dot net 2005-07-06 18:42 ` gcc2eran at tromer dot org 2005-07-08 0:41 ` wilson at specifix dot com 2005-07-08 9:18 ` gcc2eran at tromer dot org
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=20050703121248.16557.qmail@sourceware.org \ --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).