This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Volatile MEMs in statement expressions and functions inlined astrees


Alexandre Oliva wrote:
> 
> On Dec 16, 2001, Linus Torvalds <torvalds@transmeta.com> wrote:
> 
> > But not doing the read in the first case when the value is discarded is
> > also consistent.
> 
> Couldn't we do it and say it's an extension meant to increase C++
> compatibility with C and reduce surprises, especially in code such as:
We do this. It is documented in 'Extensions to C++', which I paste here

nathan

@node Volatiles
@section When is a Volatile Object Accessed?
@cindex accessing volatiles
@cindex volatile read
@cindex volatile write
@cindex volatile access

Both the C and C++ standard have the concept of volatile objects.  These
are normally accessed by pointers and used for accessing hardware.  The
standards encourage compilers to refrain from optimizations
concerning accesses to volatile objects that it might perform on
non-volatile objects.  The C standard leaves it implementation defined
as to what constitutes a volatile access.  The C++ standard omits to
specify this, except to say that C++ should behave in a similar manner
to C with respect to volatiles, where possible.  The minimum either
standard specifies is that at a sequence point all previous accesses to
volatile objects have stabilized and no subsequent accesses have
occurred.  Thus an implementation is free to reorder and combine
volatile accesses which occur between sequence points, but cannot do so
for accesses across a sequence point.  The use of volatiles does not
allow you to violate the restriction on updating objects multiple times
within a sequence point.

In most expressions, it is intuitively obvious what is a read and what is
a write.  For instance

@example
volatile int *dst = @var{somevalue};
volatile int *src = @var{someothervalue};
*dst = *src;
@end example

@noindent
will cause a read of the volatile object pointed to by @var{src} and stores the
value into the volatile object pointed to by @var{dst}.  There is no
guarantee that these reads and writes are atomic, especially for objects
larger than @code{int}.

Less obvious expressions are where something which looks like an access
is used in a void context.  An example would be,

@example
volatile int *src = @var{somevalue};
*src;
@end example

With C, such expressions are rvalues, and as rvalues cause a read of
the object, GCC interprets this as a read of the volatile being pointed
to.  The C++ standard specifies that such expressions do not undergo
lvalue to rvalue conversion, and that the type of the dereferenced
object may be incomplete.  The C++ standard does not specify explicitly
that it is this lvalue to rvalue conversion which is responsible for
causing an access.  However, there is reason to believe that it is,
because otherwise certain simple expressions become undefined.  However,
because it would surprise most programmers, G++ treats dereferencing a
pointer to volatile object of complete type in a void context as a read
of the object.  When the object has incomplete type, G++ issues a
warning.

@example
struct S;
struct T @{int m;@};
volatile S *ptr1 = @var{somevalue};
volatile T *ptr2 = @var{somevalue};
*ptr1;
*ptr2;
@end example

In this example, a warning is issued for @code{*ptr1}, and @code{*ptr2}
causes a read of the object pointed to.  If you wish to force an error on
the first case, you must force a conversion to rvalue with, for instance
a static cast, @code{static_cast<S>(*ptr1)}.

When using a reference to volatile, G++ does not treat equivalent
expressions as accesses to volatiles, but instead issues a warning that
no volatile is accessed.  The rationale for this is that otherwise it
becomes difficult to determine where volatile access occur, and not
possible to ignore the return value from functions returning volatile
references.  Again, if you wish to force a read, cast the reference to
an rvalue.

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]