Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!cs.umn.edu!talon.UCS.ORST.EDU!usenet!ogicse!intelhf!ichips!inews!hopi!bhoughto
From: bhoughto@hopi.intel.com (Blair P. Houghton)
Newsgroups: comp.std.c
Subject: Re: Unary plus
Keywords: unary plus, semantics of, order of evaluation
Message-ID: <3486@inews.intel.com>
Date: 27 Mar 91 06:48:12 GMT
Article-I.D.: inews.3486
References: <370@ptcburp.ptcbu.oz.au>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 57

In article <370@ptcburp.ptcbu.oz.au> michi@ptcburp.ptcbu.oz.au (Michael Henning) writes:
>If I want to enforce evaluation order by assigning to temporary variables, e.g.
>
>	tmp = x + y;
>	tmp -= x;
>	tmp -= y;
>	result = tmp;
>
>is it necessary to declare tmp as volatile to prevent the optimizer from
>optimizing tmp out of existence ?  Or are there some rules that say that the
>optimizer should not get rid of tmp in this case ?

Yes.  The result has to be the one expressed.  The optimizer
would be broken if it produced a result different from the
one obtained with `tmp' intact.

Optimization is moot, always, when the Standard is concerned.
The only time things are undefined is when the Standard says
they are undefined.  If your optimizer produces code that
operates otherwise, then your implementor is not telling you
the truth about conforming to the Standard.

				--Blair
				  "Moot."

P.S. However, if it can guarantee, through correct order of evaluation,
that this would give the same result:

	copy x to result;
	add y to result;
	subtract x from result;
	subtract y from result

then it's free never to allocate storage for tmp.

In fact, if it's capable of guaranteeing that the types
you've selected for x, y, result, _and_ tmp mean that the
result _is_ guaranteed to be zero (e.g., unsigned short
x,y; signed long tmp,result; enough bits in long to hold
short*short), then it may simply do

	result = 0;

or even nothing, if it can further determine that result==0
produces no effect that just 0 couldn't produce.

I.e., if you use the temporary variable, the answer
has to be the one the syntax implies, not the one that
possible optimizations might imply.

Orders of evaluation are often undefined; so optimization
is moot.  It's the syntax which says you're not being
explicit.

I know this P.S. is longer than the body, but I like muddling
around in the moot; you meet an interesting class of moot-monster
in here...