expression statements, volatiles, and C vs. C++

expression statements, volatiles, and C vs. C++

[John Regehr]

The question is, what should C and C++ compilers do with this code?

   volatile int x;

   void foo (void) {
     x;
   }

This question is not totally stupid: embedded systems use code like this 
when reading a hardware register has a useful side effect (usually 
clearing the register).

It is reasonably clear that a C compiler should load from x and throw 
away the value.  gcc does this, as do most decent C compilers.

However, g++ also loads from x and this does not appear to be supported 
by the 1998 C++ standard.  In 6.2, it is explicitly stated that for an 
expression statement, no conversion from lvalue to rvalue occurs.  If 
there's no rvalue, there should not be a load from x.

Anyway, I'm curious: is the C-like interpretation of a volatile 
expression statement considered to be a feature by the g++ maintainers? 
  If so, what is the rationale?

I haven't do extensive testing, but there do exist compiler families 
(such as those from IAR and Intel) where the C compiler loads from x and 
the C++ compiler does not.

Thanks,

John Regehr

Re: expression statements, volatiles, and C vs. C++

[Andrew Haley]

On 03/06/2010 04:43 AM, John Regehr wrote:
> The question is, what should C and C++ compilers do with this code?
> 
>   volatile int x;
> 
>   void foo (void) {
>     x;
>   }
> 
> This question is not totally stupid: embedded systems use code like this
> when reading a hardware register has a useful side effect (usually
> clearing the register).
> 
> It is reasonably clear that a C compiler should load from x and throw
> away the value.  gcc does this, as do most decent C compilers.
> 
> However, g++ also loads from x and this does not appear to be supported
> by the 1998 C++ standard.  In 6.2, it is explicitly stated that for an
> expression statement, no conversion from lvalue to rvalue occurs.  If
> there's no rvalue, there should not be a load from x.

I'm not sure this follows.  It's stated explicitly that "The
expression is evaluated and its value is discarded."  How can you
evaluate the expression without reading the volatle?

Also, there's the non-normative [Note: volatile is a hint to the
implementation to avoid aggressive optimization involving the object
because the value of the object might be changed by means undetectable
by an implementation. See 1.9 for detailed semantics. In general, the
semantics of volatile are intended to be the same in C++ as they are
in C. ]

Besides, all that changing this would do is break programs.

Andrew.

Re: expression statements, volatiles, and C vs. C++

[John Regehr]

> I'm not sure this follows.  It's stated explicitly that "The
> expression is evaluated and its value is discarded."  How can you
> evaluate the expression without reading the volatle?

I'm certainly not an expert on this material but I wouldn't think you'd 
normally read a variable in order to evaluate it as an lvalue.  My guess 
is that evaluating the expression means computing the address for 
something like "*(p+1)".

> Also, there's the non-normative [Note: volatile is a hint to the
> implementation to avoid aggressive optimization involving the object
> because the value of the object might be changed by means undetectable
> by an implementation. See 1.9 for detailed semantics. In general, the
> semantics of volatile are intended to be the same in C++ as they are
> in C. ]

Yep.

> Besides, all that changing this would do is break programs.

Well they're broken anyway since widely-used C++ compilers are choosing to 
not read the variable under these circumstances.  The obvious solution is 
"don't do that" but there's plenty of code doing this out there, and 
plenty of developers who need re-educating.

John

Re: expression statements, volatiles, and C vs. C++

[Andrew Haley]

On 06/03/10 15:54, John Regehr wrote:
>> I'm not sure this follows.  It's stated explicitly that "The
>> expression is evaluated and its value is discarded."  How can you
>> evaluate the expression without reading the volatle?
> 
> I'm certainly not an expert on this material but I wouldn't think you'd
> normally read a variable in order to evaluate it as an lvalue.  My guess
> is that evaluating the expression means computing the address for
> something like "*(p+1)".

Yes, I see your point.

>> Besides, all that changing this would do is break programs.
> 
> Well they're broken anyway since widely-used C++ compilers are choosing
> to not read the variable under these circumstances.  The obvious
> solution is "don't do that" but there's plenty of code doing this out
> there, and plenty of developers who need re-educating.

I guess.  Given that the semantics of volatile are implementation-
defined anyway, I can't see that this is a conformance issue.

Andrew.