This is the mail archive of the 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 inlinedastrees

Understood, especially in light of present circumstances.

However as noted earlier, I would have expected that:

 volatile q
 (q = 10) == 10

be unambiguously true in all cases, which would be the case if the
expression semantics were to require that the value of the expression
is equal to the value last stored into the lvalue, not necessarily it's
present value, which may be ambiguous in the case of it being volatile.

Thanks, best of luck.

> On Dec 16, 2001, Paul Schlie <> wrote:
>> 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.
> Actually, there's no such thing as portable volatile programming.
> Volatile behavior is unspecified by the standard, so compiler
> implementors are free to do whatever they want about it.  Of course,
> there are expectations that compiler implementors may be expected to
> follow, with the risk of losing users/customers.  But it's not like
> the rules are clearly stated, uniform for all compilers, etc.  You can
> probably find some portable subset of uses of volatile objects that
> will get you portable semantics.  I'd suggest sticking to rules such
> as:
> - when you want to read from a volatile object VO, always do so as the
> rvalue of an assignment to a non-volatile object O of the same type,
> in a single expression statement:
>       O = VO;
> - when you want to write to a volatile object, always use it as the
> lvalue of an assignment from a non-volatile object O of the same
> type, in a single expression statement:
>       VO = O;
> If you stick to these rules, you'll hopefully find your programs to be
> portable, even in the presence of volatile memory-mapped devices.
> Otherwise, you're likely to run into gray areas of Standards that
> different compiler implementors may have interpreted differently.  To
> wit, see the discussion we're having right now about how to deal with
> chains of assignments involving volatile lvalues, or whether volatile
> lvalues should decay to rvalues even if their values are not used.
>>  volatile q
>>  (q = 10) == 10
> I'm afraid this assertion may not hold, depending on your reading of
> the C++ Standard.

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