home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / compiler / 1503 < prev    next >
Encoding:
Internet Message Format  |  1992-09-02  |  2.3 KB
  1. Path: sparky!uunet!sun-barr!rutgers!faatcrl!iecc!compilers-sender
  2. From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
  3. Newsgroups: comp.compilers
  4. Subject: Re: -O4 in SunOS compiler
  5. Keywords: sparc, optimize, C
  6. Message-ID: <92-09-022@comp.compilers>
  7. Date: 2 Sep 92 08:38:37 GMT
  8. References: <92-08-164@comp.compilers> <92-09-017@comp.compilers>
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
  11. Organization: Computer Science, University of Melbourne, Australia
  12. Lines: 38
  13. Approved: compilers@iecc.cambridge.ma.us
  14.  
  15. chased@rbbb.Eng.Sun.COM (David Chase) writes:
  16. >>The last item is common to all optimizing compilers (at least for C),
  17. >>since aliasing analysis relies on some assumptions that must hold for a
  18. >>program, e.g.  the sequence 'p = &i; *(p+offset) = 123;' will access (a
  19. >>component of) i, but no other variable. Of course, you cannot enforce this
  20. >>in C.
  21. >
  22. >What you have there is a case of "undefined behavior" (as specified by the
  23. >ANSI and ISO C language standards).  When this is the case, it is not
  24. >"wrong" to produce code that has different results depending upon the
  25. >optimization level.  Detecting such code is difficult, but not impossible.
  26. >(Example implementation -- generate a map for all of memory, and check
  27. >each instance of pointer arithmetic and dereferencing to ensure that it
  28. >conforms to the C standard.  You may find this too costly, but it is not
  29. >at all impossible.)
  30.  
  31. No, it *is* impossible.
  32. For example:
  33.  
  34.     int i = 1, j = 2;  /* &j == &i + 1 */
  35.     int *p = &i;
  36.     if (fermats_theorem_is_false()) *(p+1) = 3;
  37.     printf("%d %d\n", i, j);
  38.  
  39. in this case, it is not possible for the compiler to determine whether the
  40. statement *(p+1) = 3 will ever be executed or not.  The best the compiler
  41. can do is issue a warning "execution of this statement would cause
  42. undefined behaviour". Similarly it is easy to come up with examples where
  43. the best the compiler can do is issue a warning "execution of this
  44. statement *might* cause undefined behaviour", eg. something like
  45.     *(p + somefunc()) = 3;
  46. where the compiler cannot detect whether somefunc() will return 0, return 1,
  47. or loop forever.
  48. -- 
  49. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  50. -- 
  51. Send compilers articles to compilers@iecc.cambridge.ma.us or
  52. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  53.