Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!husc6!cs.utexas.edu!oakhill!steve From: steve@oakhill.UUCP (steve) Newsgroups: comp.lang.fortran Subject: Re: FORTRAN porting question Summary: This is a test right? Message-ID: <1951@devsys.oakhill.UUCP> Date: 4 Apr 89 21:58:14 GMT References: <1868@quanta.eng.ohio-state.edu> Distribution: usa Organization: Motorola Inc. Austin, Tx Lines: 59 In article <1868@quanta.eng.ohio-state.edu>, kaul@icarus.eng.ohio-state.edu (Rich Kaul) writes: > > I've been given the dubious honor of porting some rather awful FORTRAN > code that someone wrote for our Suns to the HP300s we have around > here. My question involves how a particular instruction should > behave. The code I have to port has lots of loops like: > IF (I.EQ.J) GOTO 1000 > ... > DO 1000 K=1,77 > ... > 1000 CONTINUE > > My question is, how should this behave? I don't think this is good This is a test to see if I crawl out from under my rock to talk about this, right? :-) (actually I know better, but this is a variant of one of our never- dying discussions). This code is not portable. It is not good code. It is not standard conforming (see I do say this :-)). I know of at least two major compilers that will generate an infinite loop in this code. Therefore it is not even portable. It is probable that the writer wanted to jump over the loop, therefore IF (I.EQ.J) GOTO 1001 ... DO 1000 K=1,77 ... 1000 CONTINUE 1001 CONTINUE is probably what is called for. If analysis of the code shows that the writer wanted to jump into the loop. You must do the loop manually: IF (I.EQ.J) GOTO 1000 ... K = 1 1001 ... ... 1000 CONTINUE K = K + 1 IF (K.LE.77) GOTO 1001 But be aware in this second case. K is undefined at 1000 if the first jump is taken unless K is defined elsewhere. enough from this mooncalf - Steven ---------------------------------------------------------------------------- To flame someone for bad spelling or grammer is a discouragement to net discussion in a timely fashion. ---------------------------------------------------------------------------- These opinions aren't necessarily Motorola's or Remora's - but I'd like to think we share some common views. ---------------------------------------------------------------------------- Steven R Weintraub cs.utexas.edu!oakhill!devsys!steve Motorola Inc. Austin, Texas (512) 440-3023 (office) (512) 453-6953 (home) ----------------------------------------------------------------------------