Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!greg
From: greg@utcsri.UUCP (Gregory Smith)
Newsgroups: net.lang.c
Subject: Re: Optimization error?
Message-ID: <2593@utcsri.UUCP>
Date: Sun, 20-Apr-86 22:56:36 EST
Article-I.D.: utcsri.2593
Posted: Sun Apr 20 22:56:36 1986
Date-Received: Tue, 22-Apr-86 10:14:27 EST
References: <3109@reed.UUCP>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Distribution: net
Organization: CSRI, University of Toronto
Lines: 29
Summary: 

In article <3109@reed.UUCP> joey@reed.UUCP (Joe Pruett) writes:
>I contend that if the compiler could figure out that flag could
>get set to 1, then it should also figure out that flag might not
>bet set to anything, and at least issue a warning, but it should
>not optimize the expression away.
>
>Is this a bug, or a misfeature, or an inherent gotcha with fancy
>optimization?

I would say that a run-time bug in your code has propogated its way
into compile-time - an inherent gotcha.  To determine in general that
the flag may not be set is probably (?) similar to the halting problem
- it can't be done (* In General *) so it will only be detected for
simple cases. Lint apparently looks at the textual order of operations
 - the following draws a warning:

	int i,j;
	for(i=1;i<=2;++i){
		if(i==2) printf("j = %d\n", j );
		j = 123;
	}

Lint will say that j is used before it is set. An example can be set up
with goto's { goto b; a: use(j); return; b: j=0; goto a;}. In this
case it is more obvious that the code is ok but Lint will still warn.
-- 
"If you aren't making any mistakes, you aren't doing anything".
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg