This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Volatile MEMs in statement expressions and functions inlinedastrees
- From: Jason Merrill <jason at redhat dot com>
- To: Paul Schlie <schlie at mediaone dot net>
- Cc: Linus Torvalds <torvalds at transmeta dot com>, Alexandre Oliva <aoliva at redhat dot com>, Richard Henderson <rth at redhat dot com>, <gdr at codesourcery dot com>, gcc-patches at gcc dot gnu dot org
- Date: Sun, 16 Dec 2001 18:45:12 +0000
- Subject: Re: Volatile MEMs in statement expressions and functions inlinedastrees
- References: <B840DE63.3A4D%schlie@mediaone.net>
>>>>> "Paul" == Paul Schlie <schlie@mediaone.net> writes:
> (tt)(lv = rv) :: (lv = ((lt)tmp = rv, (lt)tmp), (tt)((lt)tmp))
Nope. If this was the case, then (x += y) += z would add z to some random
temporary.
>>>>> "Paul" == Paul Schlie <schlie@mediaone.net> writes:
> Fundamentally, unless I misunderstand the basis of the debate, sequencing
> of volatile accesses must be defined as being predictably controllable,
> otherwise attempting to write functionally portable sw interacting with
> often idiosyncratic hw interfaces becomes futile.
Yes.
> If it is agreed that language's expression semantics are not modified by
> volatile use, but they simply restrict subsequent optimization transforms
> available to the compiler, such that the type and sequence of volatile
> access defined in the originating source code are preserved.
Yes.
> And it is agreed that:
> volatile q
> (q = 10) == 10
No, that's where I disagree.
As Alexandre says, if you want to interact with hardware interfaces, do it
with simple assignments.
Jason