Path: utzoo!utgpu!water!watmath!clyde!feg
From: feg@clyde.ATT.COM (Forrest Gehrke)
Newsgroups: comp.sys.ibm.pc
Subject: MSC compiler options
Keywords: Watch those aliases
Message-ID: <20532@clyde.ATT.COM>
Date: 20 Jan 88 15:43:13 GMT
Distribution: na
Organization: AT&T Bell Labs, Whippany NJ
Lines: 49


> In article <3790@rosevax.Rosemount.COM> richw@rosevax.Rosemount.COM (Rich Wagenknecht) writes:

  <I've finally been able to get my windowing program to run when compiled
  <to an executable by a) turning off the optimization options in QC b) not
  <using the /Ox option in CL. One of the problems appears to be memset
  <function. When max optimizations are turned on (inline code generation)
  <memset goes wild. I'm still investigating the problem.
  <
  <One other note: If you type cl /help you'll see the /On option listed under
  <optimization options. /On turns off dangerous optimizations. Is there any
  <MS documentation on what constitutes a 'dangerous' optimization? I wasn't
  <able to find any.




 memset is one of the functions with an intrinsic form. 

I suggest that you  should compile with /Oalt which is equivalent to /Ox
except without intrinsic functions.

One should also read very carefully the discussion of aliases and
will come to the conclusion the /Oa (relax alias checking) might
be considered as a "dangerous" optimization. Consider the
following:

     func(x,y)
     {
          int i,j,*p;

          p = &x;
          i = x + y;
          *p = 2;
          j = x + y;
     }

An alias is used here in that x and *p refer to the same
memory location.  The optimizer will recognize the use of x + y
twice and will set i = j without performing the addition twice.
With alias checking relaxed, it will not recognize that I have
modified x via *p in between the two statements.  Subtle, but
documented in the compiler Users Guide under the discussion of
aliases.  

I don't recommend this kind of coding, but C allows it and it
exemplifies a dangerous optimization, if used.

Forrest Gehrke