On 02/12/2011 13:59, Andrew Haley wrote:
On Fri, Dec 2, 2011 at 5:46 AM,<paul_kon...@dell.com> wrote:
...
It's never correct to exchange volatile accesses.
That's not true. volatile accesses to different memory locations
have no special dependence. If it happens that GCC doesn't
do this kind of things then this is only because most passes
don't thouch volatile stmts at all (thus the reports for sub-optimal
code with volatile - we don't even try to do legal transformations).
I'm confused. Do you mean that in
Volatile int *a, *b;
Int j, k;
J = *a; k = *b;
it is ok to fetch *b before *a? I can't think of any device driver writer who
would expect that.
On 12/02/2011 12:27 PM, Richard Guenther wrote:
It's ok in terms of GCC internals. Whether it's ok in terms
of the C language specification I don't know (but I think it is ok).
It's not.
5.1.2.3 Program execution
Accessing a volatile object, modifying an object, modifying a file, or
calling a function that does any of those operations are all side
effects, which are changes in the state of the execution
environment. Evaluation of an expression may produce side effects. At
certain specified points in the execution sequence called sequence
points, all side effects of previous evaluations shall be complete and
no side effects of subsequent evaluations shall have taken place. (A
summary of the sequence points is given in annex C.)
...
The least requirements on a conforming implementation are: — At
sequence points, volatile objects are stable in the sense that
previous accesses are complete and subsequent accesses have not yet
occurred.
So, in here:
Volatile int *a, *b;
Int j, k;
J = *a; k = *b;
the fetch from *a must complete before the sequence point that is the
semicolon.
Andrew.
That is my understanding of volatile.
It would be fine to re-order the accesses in the expression "j = *a +
*b", since there is no sequence point between them. But with a
semicolon between them, they /must/ be correctly ordered.
Without this ordering requirement, "volatile" would be almost useless -
and C as a language would be useless for anything involving device
drivers or embedded development. And since file IO, library calls,
volatile "asm" functions, and external functions are "side effects" in
the same sense, if it is legal to re-order volatiles then it is legal to
re-order these other "side effects" - making C totally useless.
The C compiler can generate code and re-order anything it wants, as long
as the resulting program acts as though it executed the source code
directly on the C "virtual machine" in terms of the side effects - all
side effects must occur in the order given in the source code, and with
the values specified in the source code.
