From: Mark Mitchell <mark@codesourcery.com>
To: Michael Matz <matz@suse.de>
Cc: Richard Guenther <richard.guenther@gmail.com>,
Nathan Sidwell <nathan@codesourcery.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [gimple] assignments to volatile
Date: Tue, 22 Jun 2010 15:37:00 -0000 [thread overview]
Message-ID: <4C20D40B.30904@codesourcery.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1006211517460.11284@wotan.suse.de>
Michael Matz wrote:
>>> Sometimes we re-read the assigned-to object, and sometimes we do not. For
>>> instance,
>>> return vobj = data;
>>> will cause a reread of vobj, IF data is not a constant.
>
> I'd consider the latter condition a bug. I.e. the rereading must happen
> in every case.
I think that it's without question that:
vobj = data;
should not cause a read from vobj; the value is not used. I think
real-world embedded programmers would be surprised to see a read from an
I/O register there. Do you agree?
Similarly, I think that:
cond ? vobj = data : ...
should not cause a read from vobj. The conditional in this case is just
a form of if/then; it would surprise programmers if this behaved
differently from:
if (cond)
vobj = data;
Do you agree?
The case of:
x = vobj = data;
is different because the value is being used. In that case, I have no
strong opinion.
Rather than argue about this last case in theory, though, I'd be
inclined to look at existing practice. What do RealView, CodeWarrior,
Green Hills or other long-standing compilers for embedded systems do?
If there's a clear consensus, we can follow that.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
next prev parent reply other threads:[~2010-06-22 15:17 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-21 12:44 Nathan Sidwell
2010-06-21 13:26 ` Richard Guenther
2010-06-21 13:55 ` Michael Matz
2010-06-21 14:07 ` Richard Guenther
2010-06-21 14:09 ` Nathan Sidwell
2010-06-21 14:17 ` Michael Matz
2010-06-21 14:19 ` Richard Guenther
2010-06-21 14:53 ` Michael Matz
2010-06-21 14:17 ` IainS
2010-06-21 14:24 ` Michael Matz
2010-06-21 14:50 ` Nathan Sidwell
2010-06-21 15:24 ` Michael Matz
2010-06-22 11:36 ` Dave Korn
2010-06-23 20:16 ` Mike Stump
2010-06-24 11:51 ` Michael Matz
2010-06-21 15:24 ` Nathan Sidwell
2010-06-21 15:46 ` Michael Matz
2010-06-22 15:37 ` Mark Mitchell [this message]
2010-06-22 15:37 ` Jakub Jelinek
2010-06-22 15:57 ` Paul Koning
2010-06-22 15:47 ` Michael Matz
2010-06-22 15:58 ` Mark Mitchell
2010-06-23 11:38 ` Nathan Sidwell
2010-06-23 14:05 ` Mark Mitchell
2010-06-23 14:06 ` Michael Matz
2010-06-23 16:00 ` Richard Guenther
2010-06-23 16:25 ` Paul Koning
2010-06-23 17:13 ` Mark Mitchell
2010-06-23 19:16 ` Mike Stump
2010-06-24 10:22 ` Mark Mitchell
2010-06-24 15:53 ` Mike Stump
2010-06-24 16:00 ` Mark Mitchell
2010-06-24 19:37 ` Mike Stump
2010-06-25 9:37 ` Nathan Sidwell
2010-06-25 19:06 ` Mike Stump
2010-06-25 21:33 ` Mark Mitchell
2010-06-26 9:35 ` Mike Stump
2010-06-26 10:18 ` Mark Mitchell
2010-06-26 12:18 ` Richard Guenther
2010-06-26 19:52 ` Michael Matz
2010-06-26 19:57 ` Mark Mitchell
2010-06-26 20:08 ` Michael Matz
2010-06-26 22:13 ` Mark Mitchell
2010-06-28 9:20 ` Nathan Sidwell
2010-06-28 9:27 ` Nathan Sidwell
2010-06-26 10:20 ` Richard Kenner
2010-06-28 9:52 ` Nathan Sidwell
2010-06-30 22:52 ` Mike Stump
2010-07-05 8:59 ` Nathan Sidwell
2010-07-09 5:27 ` Mike Stump
2010-07-09 7:22 ` Nathan Sidwell
2010-07-16 8:10 ` Nathan Sidwell
2010-07-16 15:20 ` Mark Mitchell
2010-07-19 8:41 ` Nathan Sidwell
2010-08-13 9:56 ` Nathan Sidwell
2010-08-18 15:32 ` Mark Mitchell
2010-08-18 16:18 ` Richard Guenther
2010-08-18 18:04 ` Mike Stump
2010-08-19 11:11 ` Nathan Sidwell
2010-08-20 4:22 ` Mark Mitchell
2010-08-20 16:59 ` Mike Stump
2010-08-20 18:00 ` H.J. Lu
2010-08-20 18:33 ` Nathan Sidwell
2010-06-25 9:20 ` Nathan Sidwell
2010-06-24 10:23 ` Nathan Sidwell
2010-06-24 17:05 ` Mike Stump
2010-06-24 17:29 ` Paul Koning
2010-06-25 9:26 ` Nathan Sidwell
2010-06-25 18:20 ` Mike Stump
2010-06-28 8:49 ` Nathan Sidwell
2010-07-01 1:02 ` Mike Stump
2010-07-05 9:02 ` Nathan Sidwell
2010-07-09 5:14 ` Mike Stump
2010-07-09 7:20 ` Nathan Sidwell
2010-06-22 15:56 ` Paul Koning
2010-06-22 12:08 ` Nathan Sidwell
2010-06-22 12:25 ` Richard Guenther
2010-06-22 13:12 ` Michael Matz
2010-06-22 13:54 ` Nathan Sidwell
2010-06-22 15:21 ` Michael Matz
2010-06-22 16:12 ` Joseph S. Myers
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=4C20D40B.30904@codesourcery.com \
--to=mark@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=matz@suse.de \
--cc=nathan@codesourcery.com \
--cc=richard.guenther@gmail.com \
/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).