Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpcc01!hpcuhb!hpcllla!hpclisp!hpclscu!shankar
From: shankar@hpclscu.HP.COM (Shankar Unni)
Newsgroups: comp.sys.hp
Subject: Re: C Compiler Optimizer
Message-ID: <1340137@hpclscu.HP.COM>
Date: 31 Aug 90 02:26:49 GMT
References: <59169@bbn.BBN.COM>
Organization: Hewlett-Packard Calif. Language Lab
Lines: 62

> Alas, I also have had problems. A perfectly fine  program just stopped
> working with -O .  Minor inspection showed no ***obvious*** flaws
> in the code.  I didnt investigate enough to be able to pinpoint the
> problem so it "could" be a program error, but in this case I 
> really doubt it.   
> 
> Too bad really, because on the whole, the optimizer does a good job.
> Someone please let me know when ALL optimization bugs are fixed 
> (or atleast documented with all forms of source code that cause the problem).

And how are we to know about the bugs if people don't report them to us?

Please take the time to call HP support and let them know what problem you
are having, so that they can take a crack at isolating the problem.

Also, you'd be surprised at how many "correct" programs are exposed as
incorrect by any self-respecting optimizer.  It may be things as obscure as
variables left uninitialized along certain paths, accessing off the limits
of an array, etc.

One particularly nasty problem is if you have a signal handler that touches
a global variable. Such variables should be declared as "volatile", but
many people who inherit old code don't do so (because some other C
compilers may not have implemented this (ANSI standard) feature).

The problem is that if a function which uses this variable (and possibly
caches it in a register) is interrupted, and the signal handler modifies
this variable and returns back to that function, then it may not know that
the variable has been changed underneath it, and will continue to use the
bad value in the register.

The classic example of this is:

   extern int notavailable;	

   while (notavailable) /* do nothing */ ;
   
And the program expects some signal to set "notavailable". Oops. You should
say

   extern volatile int notavailable;

(True, this is a trivial case that should be caught, but the usage may be
much more obscure than this, and the only workaround would be for the
optimizer never to cache any globals, which is an unacceptable hit).


SUGGESTION:

If you are running HP-UX 7.0, use the optimizer flag "+OV" instead of "-O".
If your program now runs correctly, then the problem is with volatile
globals that are not declared as such.

If even that does not work, try "+O1" (which does a less aggressive level
of optimization).

BUT ABOVE ALL: try to pinpoint which part of your program is not working
after optimization, and tell HP support about it. PLEASE!!!!
-----
Shankar Unni                                   E-Mail: 
Hewlett-Packard California Language Lab.     Internet: shankar@hpda.hp.com
Phone : (408) 447-5797                           UUCP: ...!hplabs!hpda!shankar