home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / compiler / 1513 < prev    next >
Encoding:
Text File  |  1992-09-03  |  2.6 KB  |  66 lines
  1. Path: sparky!uunet!cis.ohio-state.edu!rutgers!faatcrl!iecc!compilers-sender
  2. From: dolf@toet.echo.tds.philips.nl (Dolf Grunbauer)
  3. Newsgroups: comp.compilers
  4. Subject: -O4 in SunOS compiler
  5. Keywords: sparc, optimize, C
  6. Message-ID: <92-09-032@comp.compilers>
  7. Date: 3 Sep 92 12:28:32 GMT
  8. References: <92-09-017@comp.compilers> <92-09-003@comp.compilers>
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: dolf@toet.echo.tds.philips.nl (Dolf Grunbauer)
  11. Organization: Compilers Central
  12. Lines: 51
  13. Approved: compilers@iecc.cambridge.ma.us
  14.  
  15. David Chase wrote:
  16. >>  * The compiler may produce 'wrong' code ...
  17. >>The last item is common to all optimizing compilers (at least for C),
  18. >>since aliasing analysis relies on some assumptions that must hold for a
  19. >>program, e.g.  the sequence 'p = &i; *(p+offset) = 123;' will access (a
  20. >>component of) i, but no other variable. Of course, you cannot enforce this
  21. >>in C.
  22. >
  23. >What you have there is a case of "undefined behavior" (as specified by the
  24. >ANSI and ISO C language standards).  When this is the case, it is not
  25. >"wrong" to produce code that has different results depending upon the
  26. >optimization level.  Detecting such code is difficult, but not impossible.
  27. >(Example implementation -- generate a map for all of memory, and check
  28. >each instance of pointer arithmetic and dereferencing to ensure that it
  29. >conforms to the C standard.  You may find this too costly, but it is not
  30. >at all impossible.)
  31.  
  32. An interesting simple program might be the following C code.
  33. Depending on the level of optimalisation the answer varies.
  34. I tested this on Sun 4.1.1..
  35. Options -g, -O and -O2 give a 1 while -O3 and -O4 give 2.
  36. (This program has previously been dealt with in comp.lang.c):
  37. --------------------------------------------------------------------------
  38. /* What should the following program print ? */
  39. /* (Don't mind about layout, I've done it to save space on your screen) */
  40.  
  41. #include <stdio.h>
  42.  
  43. typedef struct T { int (*func)(); int val; } T;
  44.  
  45. foo(x) T *x;      { return (0); }
  46. bar(x) T *x;      { x->val++; x->func = foo; return (0); }
  47. dum(x,y) int x,y; { return (0); }
  48.  
  49. main()
  50. {  T x; x.func = bar; x.val = 0;
  51.    dum (x.func(&x), x.func(&x));
  52.    printf("The value is: %d\n", x.val);
  53. }
  54.  
  55. /* 
  56. Possible answers:
  57. 1 because on the first call to 'bar' (i.e. x.func in main) x.func will be
  58.   set to 'foo', so x.val only increased once
  59. 2 because when calling 'dum' in main it is allowed (?) to determine the
  60.   value of x.func only once, so two calls to 'bar'. This of course depends
  61.   heavily on the evaluation of the arguments of dum.
  62. */
  63. -- 
  64. Send compilers articles to compilers@iecc.cambridge.ma.us or
  65. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  66.