home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / fortran / 4424 < prev    next >
Encoding:
Internet Message Format  |  1992-11-23  |  3.3 KB
  1. Path: sparky!uunet!olivea!decwrl!deccrl!news.crl.dec.com!rdg.dec.com!uvo.dec.com!e2big.mko.dec.com!quark.enet.dec.com!lionel
  2. From: lionel@quark.enet.dec.com (Steve Lionel)
  3. Newsgroups: comp.lang.fortran
  4. Subject: Re: Legal optimization?
  5. Message-ID: <1992Nov23.174940.19270@e2big.mko.dec.com>
  6. Date: 23 Nov 92 17:49:40 GMT
  7. References: <1992Nov21.114131.24902@alf.uib.no> <BURLEY.92Nov23105853@apple-gunkies.gnu.ai.mit.edu>
  8. Sender: usenet@e2big.mko.dec.com (Mr. USENET)
  9. Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
  10. Organization: Digital Equipment Corporation, Nashua NH
  11. Lines: 53
  12.  
  13.  
  14. |>   >>>>> "Per" == Per Steinar Iversen <iversen@vsfys1.fi.uib.no> writes:
  15. |>
  16. |>     Per> One of the students here uses VAX FORTRAN to calculate various things for his
  17. |>     Per> thesis. Recently he had some problems, which were traced down to a real bug.
  18. |>     Per> However: A result of the bug was that a square root of a negative REAL occurred.
  19. |>     Per> Yet this never made the program crash! When either a WRITE statement was 
  20. |>     Per> inserted on the next line after the SQRT or the optimization was turned off,
  21. |>     Per> then the program crashed properly... Presumably the optimizer transforms the
  22. |>     Per> code into something which is OK if the values are *not* negative. At least in 
  23. |>     Per> this program however the results were just garbage if the negative root occurred.
  24. |>
  25. |>   Welcome to the world of code optimization!  I don't think that the standard
  26. |>   has any meaning once the optimizer has gotten hold of it. Rule: the optimizer
  27. |>   is only as good as the person that wrote it. Some of them are damn good.  Most
  28. |>   are good at local 10-20 line optimization.  It is when higher level
  29. |>   optimization (i.e., so-called global optimization and inlining) is attempted
  30. |>   that things can go wrong.
  31. |>
  32.  
  33. I didn't see the original of this, but I think I can figure out what happened,
  34. and it's simpler and less sinister than some seem to think.
  35.  
  36. The VAX FORTRAN compiler can remove code whose results are unused.  If a
  37. SQRT of a negative value was computed but the result never used, the SQRT itself
  38. would also be removed.  Adding the WRITE of the value caused the result to
  39. be used and hence the error occurred.   This is a classic optimization
  40. technique and perfectly valid.
  41.  
  42. It is true the Fortran standard doesn't say much about exceptions.  I like what
  43. the Ada standard has to say in this regard.  Summarizing, section 11.6 says:
  44.  
  45.     1.  If the "canonical" order of operations does not produce an
  46.         exception, the reordered operations must not produce an exception.
  47.  
  48.     2.  A "predefined operation" (ie. an intrinsic or operator) doesn't
  49.         have to be performed if its only effect is to cause an
  50.         exception.
  51.  
  52. I take exception to the comment that "the standard [has no] meaning once the
  53. optimizer has gotten hold of it", and I believe my sentiment would be shared
  54. by any reputable compiler developer.  You might be able to ask for optimizations
  55. which make assumptions contrary to or unspecified in the standard, but a 
  56. standard-conforming program should execute in a standard-conforming manner no 
  57. matter what optimizations are applied to it.  The most clever optimizations in
  58. the world are worthless if you end up with wrong results.
  59. --
  60.  
  61. Steve Lionel                    lionel@quark.enet.dec.com
  62. SDT Languages Group
  63. Digital Equipment Corporation
  64. 110 Spit Brook Road
  65. Nashua, NH 03062
  66.