Is something wrong with the compiler ?

[Peter Holzer]

kdq at demott.COM (Kevin D. Quitt) writes:

>In article <1895 at tuvie> hp at vmars.tuwien.ac.at (Peter Holzer) writes:
>>
>>Expression:					Value:
>>(a = ~0)					(int) ~0
>>(unsigned)(a = ~0)				(unsigned) ~0
>>((unsigned)(a = ~0) >> 1)			(unsigned) MAXINT
>>(int)((unsigned)(a = ~0) >> 1)			(int) MAXINT
>>a = (int)((unsigned)(a = ~0) >> 1)		(int) MAXINT
>>
>>Anything wrong with my reasoning?

>    Yes.  Undefined order or assignment means undefined.  It is
>perfectly legitimate for the (a = ~0) assignment to actually take place
>after the a = (int)((unsigned)(a = ~0) >> 1) assignment.  That's what
>undefined order means. 

I got several replies saying about the same by email, and I think none
really covered the point I was making so I will give it a second try
with a simpler example:

Consider the following expression (initial value of a is 0):

a = (a = a + 1) + 1

This will compile (unoptimized) into:

tmp1 = a + 1
a = tmp1	*
tmp2 = tmp1 + 1
a = tmp2	*

where the lines marked with * may or may not be deferred until the next
sequence point, making the final value of a undefined, but the value of
the whole expression is the value of tmp2, which is not changed by
moving the * lines around.

The value of (a = a + 1) is 1, the actual assignment takes place
sometime before the next sequence point (But we do not know when).

So the whole expression (a = (a = a + 1) + 1) becomes (a = (1) + 1)
and the value is 2. Again, the assignment a = 2 takes place at some time
before the next sequence point. So what we have is that the expression
has the value 2, but a may have the value 1 or 2, depending on which
assignment takes place first.


On the other hand, if we have an expression like

(a = a + 1) + (a = a + 1)

it will become:

tmp1 = a + 1
a = tmp1	*
tmp2 = a + 1
a = tmp2	*
tmp3 = tmp1 + tmp2

If in this case the compiler decides tho move the line `a = tmp1' the
value of tmp2 and thus also the value of tmp3 (which is the value of the
whole expression) will change.

The compiler might use the initial value for a in both assignments so
that the result would be (1) + (1) == 2, or it might evaluate the left
subexpression (or the right, doesn't matter in this case), then assign
the new value to a, then evaluate the other subexpression with the new
value of a, yielding (1) + (2) == 3.

Any further comments?

--
|    _	| Peter J. Holzer			| Think of it	|
| |_|_)	| Technical University Vienna		| as evolution	|
| | |	| Dept. for Real-Time Systems  		| in action!	|
| __/  	| hp at vmars.tuwien.ac.at			|     Tony Rand	|