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


  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: link
Be 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).