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 inlined astrees

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

- 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.

Alexandre Oliva   Enjoy Guarana', see
Red Hat GCC Developer                  aoliva@{,}
CS PhD student at IC-Unicamp        oliva@{,}
Free Software Evangelist    *Please* write to mailing lists, not to me

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