Re: gcc volatile behaviour

[Zoltan Kocsi <zoltan at bendor dot com dot au>]

Ian Lance Taylor writes:
 > In C, assignment is a right associative operator, and its value is the
 > value of the variable to which the assignment is made.  The statement

Well, that's what I've been told. This, however, has its own problems, 
like this:

If you write:

 volatile int a;
 
 (void) a;
   
gcc will generate a fetch from a, because I accessed it then throwed
away the value. However, when I write

  (void) (b = 0);
  
gcc does not generate a re-fetch of b. Why ? If the reasoning about
the a = b = 0; case is true then gcc should generate a refetch of b,
then throw away the value - I explicitly told it to get the value of
the assignment expression and throw it away. Why is it treated
differently from either the a = b = 0 case and the a; case ?

Anyway, I've contacted the C standard committee suggesting them to change 
the wording of the assignment operator from "the value of the left
operand after the assignment" to "the value written to the left operand".

My reasoning was that the current interpretation is counter-intuitive,
shown by a few commonly used idioms which blow when they are applied
on volatile data (strcpy() and a=b=c; being prominent examples, I had
a few more complex ones as well). 'Blow' here means behaviour which is 
greatly different from what you'd intuitively expect without reading
and interpreting the standard ten times over, i.e. which is counter-
intuitive.

They replied to me indicating that they do not wish to decide which
interpretation is better, the compiler writer has every right to 
re-fetch or not to re-fetch a volatile left hand side and they 
deliberately left this slack in the standard.

I then wrote to them that apparently the writers/maintainers of
gcc/egcs do believe that the standard forces them to re-fetch the
value (note that in this regards the current and the C9X standards
are identical). I suggested a change in the wording of the standard 
which would state that it is the compiler writers' choice to re-fetch
or not. I got this:

 >                    ... there is a defect report process that allows
 > the WG14 committee to address concerns such as yours.  If you really
 > feel there is a defect in the C Standard, a defect report can be filed.
 > 
 > I really don't think that is necessary in this case (just my opinion).
 > 
 > A careful reading of the C Standard clearly does *not* require
 > re-reading the lvalue for a statement such as:
 > 
 >    a = b = c;
 > 
 > It is permitted, but not required.  Section 5.1.2.3 of C9X states in
 > part:
 > 
 >        5.1.2.3  Program execution
 > 
 >        [#1]   The   semantic  descriptions  in  this  International
 >        Standard describe the behavior of  an  abstract  machine  in
 >        which issues of optimization are irrelevant.
 > 
 >        [#2]  Accessing  a  volatile  object,  modifying  an object,
 >        modifying a file, or calling a function  that  does  any  of
 >        those  operations are all side effects,11) 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 side-effect of accessing a volatile object is not guaranteed to be
 > complete until the next sequence point.  Therefore, it is simply not
 > true that a volatile object must be re-read in between two side-effects
 > to obtain its value.  The argument that "the value of a volatile
 > left-hand side can only be retrieved by re-reading it" is false, and
 > cannot be justified by *only* reading the description of assignment
 > operators.  The C standard must be read as a whole to be understood.
 > 
 > If certain compiler writes are using such arguments then, in my opinon,
 > they are wrong.
 > 
 > Again, an implementation is allowed to re-read volatile objects but not
 > required to re-read volatile objects in-between two adjacent sequence
 > points.  This latitude is explicitly granted in the C Standard.
 >
 > ...
 
So, in the light of the above, would it be possible that in the next
release of gcc/egcs there could be a switch to change this re-fetching
behaviour, i.e. with the switch applied gcc/egcs would treat the 
value of an assignment expression being the value that is *written* to 
the left hand site (regardless of that being volatile or not) ?

Regards,

Zoltan

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com