Re: old fortran construct
From: Richard Maine (nospam_at_see.signature)
Date: 01/11/04
- Previous message: Gus Gassmann: "Re: Selection akin to SCAN for arrays"
- In reply to: Bob Lidral: "Re: old fortran construct"
- Next in thread: glen herrmannsfeldt: "Re: old fortran construct"
- Reply: glen herrmannsfeldt: "Re: old fortran construct"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 11 Jan 2004 09:23:06 -0800
> Rajarshi Guha wrote:
> I have some code that compiled with ifc (v7.0). The code snippet is
[elided]
> I'm not too sure what
> that line does: does it mean that of IPVT(J)-1 is true then jump to one
> label and false jump to the other label? But then why are there three
> numbers?
Bob explained the arithmetic IF. Note that your (Rajarshi's)
suggestion doesn't make sense. Numbers aren't true or false; numbers
are...numbers. IPVT(j)-1 is numeric and doesn't have truth or
falsity. No, you cannot assume that 0 is false and 1 true or any
other relationship between numbers and logicals.
Bob Lidral <l1dralspamba1t@comcast.net> writes:
> Unless I'm mistaken, a branch to 5 from within the inner loop causes
> only the inner loop to cycle while a branch to 5 from the outer loop
> would cause the outer loop to cycle.
You are mistaken...at least for portable or standard-conforming code.
There have been a few compilers that have allowed it (with some pretty
convoluted interpretations of some cases - try to figure out what it
means when the terminal statement is not a continue). However,
this construct has *NEVER* been either legal or portable. I've certainly
had to fix quite a few cases of it.
Note that this is not an example of the extended range of DO (a quirky
old f66 construct that became illegal in f77). This is just plain
illegal. The extended range of a DO applied *ONLY* to cases where the
code first jumps out of the DO and then back in - that isn't the case
here.
Fixing it is what I recommend that the OP do. It isn't legal code
and never was. Even if it compiles, you have no guarantee that it will
actually work correctly. My assumption is that the code was
intended to work as Bob suggests (either that or it wasn't thought
about at all and was just plain a bug...though a quick skim suggests
that it was probably intended). To make it actually legal, you'll
need to have separate terminal statements for the 2 nested loops.
> One possible rewrite just to get rid of the label ambiguity:
...
Yep. That's what I mean by having separate terminal statements for the
two loops.
> Another possible rewrite that also gets rid of the arithmetic if:
...
> There may be utilities to do such code conversions for you.
I wouldn't count on it. Most code conversion utilities require
you to start with legal code. While it is possible that there is
a utility to fix code that uses this particular nonstandard
practice, I don't recall seeing such a thing.
> An even better solution would be to convert the code to Fortran 77 (or
> later)....
As mentioned above, this isn't an f66 to f77 conversion. It is just
a conversion of ilegal to legal code.
-- Richard Maine email: my last name at domain domain: sumertriangle dot net
- Previous message: Gus Gassmann: "Re: Selection akin to SCAN for arrays"
- In reply to: Bob Lidral: "Re: old fortran construct"
- Next in thread: glen herrmannsfeldt: "Re: old fortran construct"
- Reply: glen herrmannsfeldt: "Re: old fortran construct"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|