Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!gdt!gdr!exspes
From: exspes@gdr.bath.ac.uk (P E Smee)
Newsgroups: comp.lang.c
Subject: Re: Compilers and programming style (was Re: A question of style)
Message-ID: <1990Jan10.114849.13615@gdt.bath.ac.uk>
Date: 10 Jan 90 11:48:49 GMT
References: <1989Dec22.100135.2903@gdt.bath.ac.uk> <4367@rtech.rtech.com> <1989Dec31.153241.16479@gdt.bath.ac.uk> <649@codonics.COM> <1990Jan5.100042.26760@gdt.bath.ac.uk> <2283@dataio.Data-IO.COM> <534@bbxsda.UUCP>
Reply-To: exspes@gdr.bath.ac.uk (P E Smee)
Organization: University of Bristol c/o University of Bath
Lines: 23

In article <534@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes:
>In article <2283@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes:
>>volatile int *p;
>>*p;		/* has side effects and must not be optimized away	*/
>
>Just curious - what kind of code should be generated for the above
>C fragment?

Precisely the same code as if you had written:

    pp = *p;    /* pp of a suitably sensible data type */

except that it doesn't have to include the final store into a memory location.

More complicatedly, anything the compiler writer likes which has the
same side effects as would have occurred if the value of *p had then
been used.  (If on a particular machine, the answer is provably
guaranteed always to be 'none at all', then the statement *could* be
optimized out by compilers specific to that machine.)

-- 
Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel +44 272 303132
 Smee@bristol.ac.uk  :-)  (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)