home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / compiler / 1461 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  2.6 KB
  1. Path: sparky!uunet!gatech!rutgers!faatcrl!iecc!compilers-sender
  2. From: henry@zoo.toronto.edu (Henry Spencer)
  3. Newsgroups: comp.compilers
  4. Subject: constant folding vs exceptions
  5. Keywords: parse, optimize
  6. Message-ID: <92-08-163@comp.compilers>
  7. Date: 26 Aug 92 20:34:53 GMT
  8. References: <92-08-114@comp.compilers> <92-08-132@comp.compilers>
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: henry@zoo.toronto.edu (Henry Spencer)
  11. Organization: U of Toronto Zoology
  12. Lines: 43
  13. Approved: compilers@iecc.cambridge.ma.us
  14.  
  15. wjw@eb.ele.tue.nl (Willem Jan Withagen) writes:
  16. >Now I don't want to open another tarpit again, but this certainly is going
  17. >to have effects on the semantics of the used program...
  18. >[This was for integer expressions in C, which traditionally haven't paid
  19. >much attention to overflows...
  20.  
  21. In fact, ANSI C handed down a much stricter line on this: expressions
  22. execute as written, with the only escape clause being the "as if" rule
  23. (which says that the compiler can do anything it pleases if the user can't
  24. legally tell the difference).  You can still do the things that old C
  25. compilers do, but only if you are generating code that ignores integer
  26. overflow.  Alternatively, you may still be able to do some optimization if
  27. you generate code that catches the cases where overflow would matter --
  28. ANSI C doesn't constrain what *happens* when overflow occurs, so the
  29. program doesn't have to dump core in precisely the same way as the
  30. unoptimized one would.  The only restriction is that if overflows are
  31. visible, optimizations can't add or remove overflows.  This is for
  32. integers, of course; for floating point, optimizations are a lot more
  33. tightly constrained under "as if".
  34.  
  35. A subtle point worth mentioning here...  A *compiler* that ignores the
  36. possibility of overflow might not generate *code* that ignores overflows.
  37. On many machines, overflow is figured into how some of the conditional
  38. branches work.  If the generated code is to truly ignore overflows, the
  39. compiler has to be aware of the issue and be careful about the code it
  40. generates.  The original Ritchie C compiler, for example, generated code
  41. that could malfunction in peculiar ways in the presence of overflow.
  42. Consider the following with 16-bit ints:
  43.  
  44.     int foo;
  45.  
  46.     foo = 32767;
  47.     if ((foo += 200) < 0)
  48.         printf("%d is negative\n", foo);
  49.     else
  50.         printf("%d is non-negative (!)\n", foo);
  51.  
  52. Guess which message you got out of code from the Ritchie compiler...
  53. -- 
  54. Henry Spencer @ U of Toronto Zoology, henry@zoo.toronto.edu  utzoo!henry
  55. -- 
  56. Send compilers articles to compilers@iecc.cambridge.ma.us or
  57. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  58.