This is the mail archive of the
mailing list for the GCC project.
Re: [gimple] assignments to volatile
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Nathan Sidwell <nathan at codesourcery dot com>
- Cc: Mike Stump <mikestump at comcast dot net>, Michael Matz <matz at suse dot de>, Richard Guenther <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 16 Jul 2010 08:20:38 -0700
- Subject: Re: [gimple] assignments to volatile
- References: <4C1F5380.firstname.lastname@example.org> <AANLkTimzBtuWYWnzMkmDyM6Y490EIwQJxaDI_higMvJs@mail.gmail.com> <Pine.LNX.email@example.com> <4C20D40B.firstname.lastname@example.org> <Pine.LNX.email@example.com> <4C20D891.firstname.lastname@example.org> <4C21E361.email@example.com> <4C220762.firstname.lastname@example.org> <025B27D1-E620-4BA2-A113-FD28747E2762@comcast.net> <4C22F307.email@example.com> <4936DDA8-4C55-4CF8-8CA7-D8B4435863BF@comcast.net> <4C236C7A.firstname.lastname@example.org> <97293849-2D1F-4DE5-9B35-199E26005768@comcast.net> <4C2451CA.email@example.com> <E1CA7E86-EEE4-4EB7-8CAF-0FA59DD694DB@comcast.net> <4C2852F4.firstname.lastname@example.org> <CAC3E597-C092-4A46-9EEF-96589BC6794B@comcast.net> <4C319EF7.email@example.com> <3721950A-1FF1-441A-A22E-D19507FC36FB@comcast.net> <4C36CE16.firstname.lastname@example.org> <4C4013FB.email@example.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
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,
vobj = 3;
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.
(650) 331-3385 x713