Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!samsung!xylogics!world!burley From: burley@world.std.com (James C Burley) Newsgroups: comp.lang.fortran Subject: Re: Function calls in the middle of subroutine CALLs? -- Is it standard fortran 77 ???? Message-ID: Date: 21 Jul 90 07:37:45 GMT References: <57505@lanl.gov> <286@sun13.scri.fsu.edu> Sender: burley@world.std.com (James C Burley) Followup-To: mayne@nu.cs.fsu.edu (Bill Mayne) Organization: The World Lines: 72 In-Reply-To: mayne@VSSERV.SCRI.FSU.EDU's message of 20 Jul 90 16:27:23 GMT In article <286@sun13.scri.fsu.edu> mayne@VSSERV.SCRI.FSU.EDU (William (Bill) Mayne) writes: In article burley@world.std.com (James C Burley) writes: > >I guess the real issue is that Fortran is a language primarily for the >expression of mathematical formulas, in which side effects and operation >ordering do not play a role. When you care about side effects and ordering, >you are told to use separate statements (or other sequence points... > Correct me if I am wrong (I am new to high performance computing), but isn't there risk that an optimizing compiler will rearrange even separate statements in some cases. Relying on side effects seems quite dangerous. Your explanation was so good I'd like to hear more. Regards. I used to work on just such an optimizer for a vector processor, and you're right, there is such a risk: but technically the risk is that the compiler is broken (has a bug in that it is overzealous) or your program doesn't conform or you've forgotten to tell the compiler that your program doesn't conform in some way to the standard (F77 or F90 or whatever). The compiler can rearrange statements if it determines that the results will be exactly the same (computationally, not just mathematically) as if they had been executed in the original order. Besides compiler bugs, a typical problem resulting in a bug with such a compiler is that your program isn't actually standard conforming, and you might never find this out on traditional (non-vector) machines. For example: REAL A(100) CALL VADD(A(1),A(2),A(3),98) !Add neighboring elements, store !in next element, to sum forward SUBROUTINE VADD(IN1,IN2,OUT,N) REAL IN1(N),IN2(N),OUT(N) DO I=1,N OUT(I) = IN1(I) + IN2(I) END DO END (Please excuse any typos.) This program should run fine on most traditional machines, but might very well break on an optimizing compiler for a parallel machine. Why? Because the optimizer is allowed to assume it can read any element of IN1 and IN2 before it writes any element of OUT in VADD, and that's allowed because the arrays may not overlap according to the Fortran standard (actual arguments may not overlap with each other or with entities in common during a procedure call if the procedure or any procedure it calls defines any entity involved in the overlap, is a "simple" summary of the rule). This surprising restriction (not found in any other common languages as far as I know) specifically exists to provide supercomputers with the opportunity for running most Fortran applications faster than would otherwise be possible without the restriction. You'd be surprised how much slower a pipelined loop has to run to allow for overlapping arrays! So, in summary, there shouldn't be a risk with statement-reordering compilers, but in practice there is because the compiler might be too agressive (have a bug) or your program violates some requirement that the compiler imposes (from the standard) without notifying the compiler of such a violation. (I've heard some compilers, for example, provide a directive that says "dummy arrays IN1, IN2, and OUT may overlap", which can slow down execution but at least get the code to work.) This is fun, but I've spent days tracking down "bugs" in the compiler I used to work on that turned out to be exactly the kind of violation shown above. One of the offenders was a 3rd-party vendor of math packages primarily for supercomputers, written in Fortran (though because they may have fixed the problem by know, I won't name them).