From: Mark Mitchell <mark@codesourcery.com>
To: Nathan Sidwell <nathan@codesourcery.com>
Cc: Mike Stump <mikestump@comcast.net>, Michael Matz <matz@suse.de>,
Richard Guenther <richard.guenther@gmail.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [gimple] assignments to volatile
Date: Fri, 16 Jul 2010 15:20:00 -0000 [thread overview]
Message-ID: <4C4078C6.1020104@codesourcery.com> (raw)
In-Reply-To: <4C4013FB.8090203@codesourcery.com>
Nathan Sidwell wrote:
> Is there consensus on what the semantics should be?
>
> Any suggestions as to how to move forward?
In the abstract, I think the EDG semantics make the most sense. I
think the VC++ semantics are plausible, but extreme. I think the
various in-between states that GCC has adopted over the years are just
woefully inconsistent.
So, my first preference would be to adopt the EDG semantics, and my
second preference would be to adopt the VC++/trunk semantics. My
preference for the EDG semantics is somewhat offset to some extent by
the fact that our current semantics are "more like" GCC's past behavior,
i.e., they are more backward-compatible.
One of the reasons I do not like the VC++/trunk semantics are that using
assert-like macros will change behavior. For example:
#define check(X, Y) (X) ? (Y) : abort()
check (condition, vobj = 3);
I think it's quite surprising that this generates a *read* from vobj,
even though:
vobj = 3;
does not.
I would prefer not to insert reads except where absolutely required
because (a) they may change the state of hardware in surprising ways,
and (b) they cost cycles. In short, by requiring rereads, we're setting
GCC up to underperform competing compilers on embedded systems.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
next prev parent reply other threads:[~2010-07-16 15:20 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
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 [this message]
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=4C4078C6.1020104@codesourcery.com \
--to=mark@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=matz@suse.de \
--cc=mikestump@comcast.net \
--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).