NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/fortran/4420

Internet Message Format | 1992-11-23 | 3.6 KB

Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!tamsun.tamu.edu!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!burley
From: [e-mail] (Craig Burley)
Newsgroups: comp.lang.fortran
Subject: Re: Legal optimization?
Date: 23 Nov 92 10:58:53
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
Lines: 52
Message-ID: <[e-mail]>
References: <[e-mail]>
    <[e-mail]>
NNTP-Posting-Host: apple-gunkies.gnu.ai.mit.edu
In-reply-to: [e-mail]'s message of 22 Nov 92 06:56:07

In article <[e-mail]> [e-mail] (Lawrence R. Dodd) writes:

   >>>>> "Per" == Per Steinar Iversen <[e-mail]> writes:

     Per> One of the students here uses VAX FORTRAN to calculate various things for his
     Per> thesis. Recently he had some problems, which were traced down to a real bug.
     Per> However: A result of the bug was that a square root of a negative REAL occurred.
     Per> Yet this never made the program crash! When either a WRITE statement was
     Per> inserted on the next line after the SQRT or the optimization was turned off,
     Per> then the program crashed properly... Presumably the optimizer transforms the
     Per> code into something which is OK if the values are *not* negative. At least in
     Per> this program however the results were just garbage if the negative root occurred.

   Welcome to the world of code optimization!  I don't think that the standard
   has any meaning once the optimizer has gotten hold of it. Rule: the optimizer
   is only as good as the person that wrote it. Some of them are damn good.  Most
   are good at local 10-20 line optimization.  It is when higher level
   optimization (i.e., so-called global optimization and inlining) is attempted
   that things can go wrong.

   The solution in all three cases was to break up one of the subroutines into a
   set of smaller routines.  In general, this is good programming practice but
   also helps the optimizer from becoming too cavalier with my code :-)

Actually, the problem is not with the optimization, but with the code
you're feeding to it.  More precisely, instead of "I don't think the standard
has any meaning once the optimizer has gotten ahold of it", the truth of
the matter is this:

    The standard has no meaning once nonconforming code is involved.
    (Aside from stating that it has no meaning, i.e. that the results
    are "undefined".  Note that the Fortran 90 standard actually tries
    to give itself some meaning as far as insisting that some cases of
    nonconforming code be diagnosed, but those are, I think, pretty much
    all cases of diagnosis at what we think of as compile time, not
    run-time cases like SQRT of a negative number.)

It's nice that a system diagnose programmer errors whenever it can, but
it's even nicer when it stops doing that when you specify -O[something]
and the cost of diagnosis vs. just assuming the program is correct is
nonzero.

Certainly there have been optimizers and optimizations that make code run
faster assuming that certain ordinarily conforming activities aren't
undertaken by the program -- and in some cases, those assumptions weren't
documented or perhaps even recognized by the designers of the optimizations --
but the case cited above, as far as I know, doesn't fit into these categories.
It seems to me that the code was wrong, not the optimizer.
--

James Craig Burley, Software Craftsperson    [e-mail]
Member of the League for Programming Freedom (LPF) [e-mail]