do 10 i=1,m
c write (6, *) "I ", i
do 5 j=1,n
c write (6, *) "J ", j
if (j .eq. 3) then
write (6, *) "J ", j
write (6, *) "I ", i
<and so on...>
What I've seen is, when execution hits 'goto 10' another iteration of
the outer loop is started. Is this the expected/prescribed behavior
and not something that can vary between (properly written) compilers?
In which case I can just replace 'continue' with 'end do' and remove
labels in the 'do' statements.
Couldn't this sequence: 'goto 10' --> '10 continue' --> <and so on...>
> I'm looking to convert some older f77 'do <label>' constructs to the
> 'do-end do' style. Using this snippet:
> do 10 i=1,m
> c write (6, *) "I ", i
> do 5 j=1,n
> c write (6, *) "J ", j
> if (j .eq. 3) then
> goto 10
> end if
> write (6, *) "J ", j
> 5 continue
> write (6, *) "I ", i
> 10 continue
> <and so on...>
> What I've seen is, when execution hits 'goto 10' another iteration of
> the outer loop is started. Is this the expected/prescribed behavior
> and not something that can vary between (properly written) compilers?
> In which case I can just replace 'continue' with 'end do' and remove
> the labels in the 'do' statements.
Yes, that is specified by the standard. You could also replace the goto
with an appropriate cycle. I'd probably write the above as
outer: do i = 1 , m
inner: do j = 1 , m
if (j==3) cycle outer
end do inner
end do outer
Well, actually, I might be tempted to rewrite further, depending on what
was in the .... parts. The above is pretty much just a straight syntax
change to do the same thing, without touching anything else.
> Couldn't this sequence: 'goto 10' --> '10 continue' --> <and so on...>
> happen too?
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
As long as the loops ends in CONTINUE, yes.
DO loops can end in other statements, in which case the GOTO
is to that statement.
do 1 i=1,10
if(i.lt.5) goto 1
1 write(*,*) '*'
can be replaced with
if(i.lt.5) goto 1
1 write(*,*) '*'
Thanks, Richard. I've seen EXIT but CYCLE is new to me. Can CYCLE
through an arbitrarily deep nest?
A problem is that you can replace the statement without its label, and
supply a following labelled CONTINUE statement, if and only if that
label is not branched to from elsewhere in the loop. In that case,
such a change would not execute the branched-to statement. Quite
tricky to code, but I got it correct.
I am quite happy to use the original form of the DO loop as the only
kind needed; I never found a use for the others.
The one joy was getting to use that added IF...THEN...ELSE structure,
to get rid of labels and get some more logical structure in my
But then you really have to indent to keep track of the nesting
> On Feb 7, 4:24 pm, nos...@see.signature (Richard Maine) wrote:
> > outer: do i = 1 , m
> > ...
> > inner: do j = 1 , m
> > ...
> > if (j==3) cycle outer
> > ...
> > end do inner
> > ...
> > end do outer
> Thanks, Richard. I've seen EXIT but CYCLE is new to me. Can CYCLE
> punch through an arbitrarily deep nest?
Yes, provided that you use a construct name as I did above (that's the
"inner" and "outer", which are just names I arbitrarily chose.) If you
don't specify a construct name on an exit or cycle, it applies to the
innermost loop. My personal style is to always use a construct name when
the construct hs an exit or cycle; I think it helps clarity to have the
statement specifically say what it is exiting or cycling (particularly
with exit, as it would be easy to misread exit as meaning to exit
various possible things, including the procedure, or even the whole
Wait, what? You're saying this (for instance):
do 666 i=1,10
666 write (*, *) ...
Is the same as this:
do 666 i=1,10
write (*, *) ...
So long as there are no 'GOTO 666' statements inside the loop?
Yes, I'm keeping an eye out for these booby traps.
In my case, I'm using do/end-do blocks. The hitch is, in the
original program, the original author has multiple do loops
all terminating at a single CONTINUE which, in some cases, is
also the target of GOTOs. Just nutty.
Neat. I didn't know you could label end-do that way. Are those
functional or just for readability (i.e. does the compiler pay
to those labels)? And this is "proper" (not obsolescent) in f90 on
I seem to recall that gfortran (-pedantic ?) complains when I try to
stuff like this:
do 666 i=1,10
666 end do
Which is just a bass-ackwards version of what you posted.
Do you (or anyone else, really) know of a text editor that can
corresponding do/end-do lines? Preferably something linuxy and free.
> In my case, I'm using do/end-do blocks. The hitch is, in the
> original program, the original author has multiple do loops
> all terminating at a single CONTINUE which, in some cases, is
> also the target of GOTOs. Just nutty.
Watch out for a big gotcha there. In particular, all the gotos must be
from within the innermost of the loops that terminate on that statement.
Otherwise the code is nonstandard. I have seen codes like
do 100 i = 1 , n
if (something) goto 100 !--- This is wrong.
do 100 j = 1 , n
if (something_else) goto 100 !--- This one is ok
There have been compilers that accepted this nonstandard code. There
have been programers that wrote code depending on the particular
compiler behavior. I have talked to multiple such programers who were
convinced (but were wrong) that this was standard conforming code. I've
also coresponded with one compiler developer (for SGI, so yes, it was a
while ago) who was equally convinced that the standard allowed this. It
took a while, but I finally helped the compiler developer understand
where he had gone wrong. He had used his own concept of what the range
of a DO loop would be, rather than reading the actual definition of the
standard. I recall thinking that he'd have run into lots of
inconsistencies if he had tried to apply his definition throughout, but
I think it was more something that he had used to rationalize his answer
than to actualy derive it.
Anyway, don't do that one. If you have old code that does it, you need
to study code fairly carefully to make sure you know what it was trying
to do. Odds are that the first goto was trying to cycle the outer loop
and the second one was trying to cycle the inner loop, but when you have
nonstandard code like this, you can't always be sure. That's sometimes
the intent, but I have also seen cases where it was just plain a bug in
the code on the order of a typo in the statement number in the goto.
> On Feb 7, 6:00 pm, nos...@see.signature (Richard Maine) wrote:
> > Eric <einazaki...@yahoo.com> wrote:
> > > On Feb 7, 4:24 pm, nos...@see.signature (Richard Maine) wrote:
> > > > outer: do i = 1 , m
> > > > ...
> > > > inner: do j = 1 , m
> > > > ...
> > > > if (j==3) cycle outer
> > > > ...
> > > > end do inner
> > > > ...
> > > > end do outer
> > > Thanks, Richard. I've seen EXIT but CYCLE is new to me. Can CYCLE
> > > punch through an arbitrarily deep nest?
> > Yes, provided that you use a construct name as I did above
> Neat. I didn't know you could label end-do that way. Are those labels
> functional or just for readability (i.e. does the compiler pay attention
> to those labels)? And this is "proper" (not obsolescent) in f90 on up?
Yes, the compiler pays attention. It will bitch if you use them and they
they don't match. In the case above the construct name is actually
important to tell the compiler which loop it is you are cycling. Without
the construct name, it would cycle the inner loop, which isn't what you
wanted. Yes, it tells the compiler in addition to the human reader.
And yes, it is all "proper" current form and in no danger at all of
> I seem to recall that gfortran (-pedantic ?) complains when I try to
> do stuff like this:
> do 666 i=1,10
> 666 end do
Hmm. I'm not sure what is obsolescent about that. I'm not entirely
convinced that it is, though I'd believe it could be. Not worth checking
at the moment. It isn't a style I'd use anyway, as it mixes the old
numeric label with the newer do/enddo style, but I think it is valid.
> Do you (or anyone else, really) know of a text editor that can highlight
> corresponding do/end-do lines? Preferably something linuxy and free.
I suspect they exist, but I'm not up on that. Emacs is almost bound to
be able to, but that's just because it can do pretty much anything; I
haven't actually checked that particular feature. Someone else?
Man, you're just all kinds of helpful. It turns out that the program
working on was originally built with SGI's f77 compiler. This would
around IRIX 3/4 which is around early to mid '90s. I should take a
harder look at that program on Monday.
> Man, you're just all kinds of helpful.
Thank you. I love getting comments like that. Pretty much makes my day.
Wait, how is that non-compliant? I thought gotos can jump to anywhere
and with do loops, it's only a no-no to jump into them? I should do
Does this make your snippet kosher?
do 101 i = 1 , n <-- changed label
if (something) goto 101 <-- changed target
do 100 j = 1 , n
if (something_else) goto 100
101 continue <-- added
Even if the above is correct, I'm still not getting it.
Just to be clear, you're talking about what the standard
allows, not what's good programming practice, right? For
instance, spaghetti code is always bad practice but not
> On Feb 7, 10:46 pm, nos...@see.signature (Richard Maine) wrote:
> > do 100 i = 1 , n
> > ...
> > if (something) goto 100 !--- This is wrong.
> > ...
> > do 100 j = 1 , n
> > ...
> > if (something_else) goto 100 !--- This one is ok
> > ...
> > 100 continue
> Wait, how is that non-compliant? I thought gotos can jump to anywhere
> and with do loops, it's only a no-no to jump into them?
Well, there are quite a few restrictions on where gotos can go to, but
yes, that's the relevant one here. Because this is a jump into the inner
loop. That's exactly the problem (and the misunderstanding of the SGI
developer I referred to). The 100 counts as being in both loops.
> Does this make your snippet kosher?
> do 101 i = 1 , n <-- changed label
> if (something) goto 101 <-- changed target
> do 100 j = 1 , n
> if (something_else) goto 100
> 100 continue
> 101 continue <-- added
Yes, because then the first goto isn't jumping into the inner loop.
> Just to be clear, you're talking about what the standard
> allows, not what's good programming practice, right?
Right. It is non-compliant (and lots of compilers will refuse to compile
>> Do you (or anyone else, really) know of a text editor that can highlight
>> corresponding do/end-do lines? Preferably something linuxy and free.
> I suspect they exist, but I'm not up on that. Emacs is almost bound to
> be able to, but that's just because it can do pretty much anything; I
> haven't actually checked that particular feature. Someone else?
I tend to just use emacs as it comes out of the box. In that case
tabbing on each line indents each loop to an appropriate depth. It also
will briefly highlight a block if you type "end<tab>" and add the
appropriate 'do', 'subroutine' etc. for you, including the name if it's a
named block. It can probably do more, but coming from the land of TECO I
don't expect much of my editors. I just typed this nonsense programme in,
with a source extension of .f90 and only typed "end<tab>" on each of the
appropriate lines (and a tab on each of the other lines). The
upper-casing of keywords is a customisation available through the Options
menu. There's colouring too, but short of posting a URL to a screen-grab I
can't show that on Usenet.
outer: DO i=1,10
IF (j.EQ.3) CYCLE
inner: DO j=1,10
END DO inner
END DO outer
END PROGRAM foo
Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".
I'm still amazed anyone would use emacs, but C'est la vie :)
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
> > I seem to recall that gfortran (-pedantic ?) complains when I try to
> > do stuff like this:
> > do 666 i=1,10
> > ...
> > 666 end do
> Hmm. I'm not sure what is obsolescent about that.
I seem to remember something related to this regarding the
mil-std-1753 extensions to f77. I forget now if the statement
labels were required or if they were not allowed, but I don't think
they were optional. However, many (most?) compilers that
implemented do-enddo allowed the numeric labels in an optional way,
which was really an extension to an extension.
The practical difference in labeled do loops and numeric statement
labels, as far as compilers are concerned, is the idea of "tame"
labels. A tame label is a statement label that has only limited
branches to it, whereas a wild label can be accessed by anywhere
within the subprogram. F77 introduced some limitations on the wild
numeric statement labels in earlier dialects of fortran (e.g. it
eliminated "extended do loop ranges"), and the labeled (and
unlabeled) do loops in f90 extend that general idea even further.
$.02 -Ron Shepard
> I'm still amazed anyone would use emacs, but C'est la vie :)
Au contraire, mon ami, c'est la guerre! ;-)
But seriously, I use cygwin/X11/fvwm2 on my work and home PCs to
access mainly Linux machines at work, at home, and at CERN. I can access
more than a dozen different machines in a typical work-day, before we even
consider the Grid jobs. It's a simple solution that works.
For the specific example you have shown (termination of inner loop as a
function of inner loop index) I would write it as follows:
write (6, *) "J ", j
write (6, *) "I ", i
<and so on...>
I'd also be tempted by at least something along those lines. But be
careful. It does take some attention to get everything right. Note that
the OP's code does not actually just terminate the inner loop. It cycles
the outer one (that being why I suggested the cycle statement). Yes,
there is a difference. The WRITE statement for i will be executed m
times in your version, but will never be executed in the OP's version if
n exceeds 2.
Indeed, and I am on the losing side :-(
I use Emacs, with some hairy customisation (to disable as many of
its gimmicks and gotchas as I trip across) because it is the only
way that I can run a WYSIWYG text editor with even half-tolerable
ergonomics. If there is a better hole, I would go to it. For
those who knew it, the one with the best ergonomics was BBC VIEW;
it has, as far as I know, never been equalled - even though it was
nowhere near optimal.
> In article <1iusb8o.9vb4wi4eec6oN%nos...@see.signature>,
> nos...@see.signature (Richard Maine) wrote:
> > > I seem to recall that gfortran (-pedantic ?) complains when I try to
> > > do stuff like this:
> > >
> > > do 666 i=1,10
> > > ...
> > > 666 end do
> > Hmm. I'm not sure what is obsolescent about that.
> I seem to remember something related to this regarding the
> mil-std-1753 extensions to f77. I forget now if the statement
> labels were required or if they were not allowed, but I don't think
> they were optional.
They wer required in 1753.
Change lost to los to email
No. The terminal statement (10) is always part of (i.e., inside) the loop.
I'm in the process of reconstructing an old Fortran 77 program that I
in 1982 - 1983 too. I haven't coded in Fortran since back then and I'd
wondering whether to stick with g77 or upgrade to maybe GFortran,
allow me to use Fortran 95. I decided to stick with Fortran 77 to keep
relearning curve as short as possible, but then I came across this
was simply intrigued by how CYCLE and EXIT make the code so much
all those CONTINUEs and GOTOs that I used to rely on.
I found that EMACS just wouldn't indent the code to show off the
labels for the
DOs though. I used M-x indent-region after selecting the region to
Here's the code; it's an example I modified from chapter 5 of
Programming in FORTRAN" by Arthur S. Radford in order to play with
EXIT. I bought this book a couple of decades ago and I now finally
opportunity to use it. I'm at chapter 5, but I just couldn't help
with the DOs in this thread.:-) :
! This program reads in a number N whose value
! determines whether or not there the file has ended.
! If the file is not ended, a second number is read,
! which triggers an alarm depending on its value.
max = 20
index : do i = 1, 3
sum = 10
print *, 'Enter value for N'
read *, n
if (n .lt. 0) then
print *, 'End of File'
alarmer : do j = 1, 5
if (sum .gt. max) then
alarm = .true.
print *, alarm, ' Sum is greater than Max'
print*, 'Sum is less than Max'
print *, 'Enter value for X'
read *, x
sum = sum + x
end do alarmer
end do index
Could the problem with the indentation be my version of g77? I'm using
gcc 3.2 (yes, very old box this one).
Freedom - no pane, all gaiGN!
I don't know or use EMACS but can't see how the choice of the specific
compiler would/could possibly matter.
I would think the interaction would be based on the customizations and
what EMACS assumes about file formatting based on the edited file name
extension (.f, .for, .f90/.f95, etc., etc., ...) would control what it
knows about source formatting. But, that's just guessing...
No you're not guessing. I was just about to post back with an "oops,
brain is tired" remark. I've been far too obsessed with deciding on
g77 vs g95 vs gfortran.
Of course it's not the compiler, I really meant to cite my version of
EMACS, and not g77-gcc. I'm running EMACS 21.1. A more recent version
of EMACS would probably handle the indentation for .f files better.
G77 will compile .f, .for, or .FOR files. It's quite possible that
EMACS might treat these filetypes slightly differently. Otherwise, I
would need to code my own EMACS customizations to correct the problem.
I probably won't spend time doing this just now though, time is tight.
> No you're not guessing. I was just about to post back with an "oops,
> brain is tired" remark. I've been far too obsessed with deciding on
> g77 vs g95 vs gfortran.
> Of course it's not the compiler, I really meant to cite my version of
> EMACS, and not g77-gcc. I'm running EMACS 21.1. A more recent version
> of EMACS would probably handle the indentation for .f files better.
> G77 will compile .f, .for, or .FOR files. It's quite possible that
> EMACS might treat these filetypes slightly differently. Otherwise, I
> would need to code my own EMACS customizations to correct the problem.
> I probably won't spend time doing this just now though, time is tight.
Ah, makes sense.
I'd only suggest choosing between the F95 compilers rather than an
F77-limited one, particularly since they are almost completely a superset.
If you have existing code to port, I'd try it w/ them and see if there's
something they don't handle that is actually owing to the difference in
language (ie, not an extension).
Before I began the project to relearn Fortran last week, I did some
Googling on the GNU compilers. Apparently, gfortran compiles all of
fortran 77 code whereas g95 doesn't always. The plan, right now, is to
reconstruct the f77 code primarily as f77 with some of the nice f90
features allowed by g77 - like CYCLE and EXIT.
When I have more time, I'll consider upgrading the code to the Fortran
95 or 2003 standard. Who knows, maybe by then I'll want to play with
As for upgrading EMACS, gcc etc etc, it might be easier to install a
new GNU/Linux distribution rather than get into rpm dependency
headaches and never ending library upgrades.:-(
> Apparently, gfortran compiles all of
> fortran 77 code whereas g95 doesn't always.
Really? What particular f77 features are you referring to?
In particular, I wonder whether you are actually talking about f77 or
about some extensions. That's a question that needs to be asked because
some people have been known to define "f77" as meaning whatever their
particular program uses, which doesn't always have much to do with the
f77 standard, and occasionally includes features that didn't work on
most f77 compilers.
If you are talking about such extensions, I can well imagine it. I
actually tend to think that accepting too large a plethora of extensions
can be a negative for several reasons, but that's a side matter.
I don't recall running into any standard f77 features that g95 didn't
support. But then, there are some f77 features that I don't tend to use
and thus might not notice. The ASSIGN statement and its "friends" occur
to me. That one has some subtle points that can make implementation
tricky. And it is one I never use (well, not in the last several
decades; I think I used some in the early 70's) and so might not have
noticed being omitted.
It's because of a slightly obscure example of a fixed-format/free-
Short answer: Make sure you are in f90-mode rather than fortran-mode
and then try indent region ( or f90-indent-region, that's what I
use ). That turns it into
end program ifwithdo
Slightly longer answer: Fortran mode is really for fixed format
Now while fixed format is still perfectly legal, fortran mode in emacs
does not seem to have been changed to accept any f90 features or
except for those that were common f77 extensions. f90-mode is for
free format Fortran and understands the new stuff, so can indent
And yes, this is a pain for old code which has been written in fixed
and you want to modernise. However I do not have anywhere near the
of how to update Fortran mode to do the right thing, but it would be
nice if someone, somewhere bot does and has the inclination to update
For existing fixed format code you might be able to stick it through
a format converter and then use f90-mode. Have a look near the bottom
However you may have other constraints on the project that stop you
Hope this helps,
In old codes, there is only one possible interpretation of
When the terminal statement was reached, the control variable
of the most recently executed DO statement was incremented.
However, the 1966 standard was quite explicit that the first GOTO above
was illegal: If there is a GOTO to the terminal statement
of multiple DOs, that GOTO can be only in the innermost DO.
Yes, f90 mode is simply magical! The wonders of EMACS!
I saved the .f file with a .f90 extension and used M-x indent region;
I got the identical result you did.
Of course, g77 refuses to compile the file , even with the -ff90, -
ffree-form, or -fno-fixed-form options. It seems I'll have to spend
some time upgrading and installing gfortran or g95. I'll leave that
headache for now though and just work with g77.
> And yes, this is a pain for old code which has been written in fixed
> and you want to modernise. <snip>
> For existing fixed format code you might be able to stick it through
> a format converter and then use f90-mode. Have a look near the bottom
> However you may have other constraints on the project that stop you
> doing this,
Yes, there is a significant constraint - I don't have the original
code either in electronic or hardcopy format. All I've got is my
typist's 1983 interpretation of the printout, which is quite useless
for reconstruction. You can see a copy here under the directory
Thank you, this really helped. It would have taken me some more time
to discover f90 mode. I'll save copies in f90 format as I go along so
I can compile and test at the end with the new compiler to be
installed. Of course EMACS would have an f90 mode.:-)
I don't recall the details now. In realised that there were two
apparently competing GNU Fortran compilers and Googled g95 vs gfortran
(and vice-versa). Among the hits were information for transitioning
from 95 from 77:
which listed Fortran 95 deletions, Constructs considered harmful, and
Constructs considered obsolete; as well as discussions like this one:
From what I gather, Fortran 77 is a proper subset of Fortran 90, but
not of Fortran 95. It is possible that the g95 developers strictly
adhered to the standards, while gfortran allowed everything from
Fortran 77. This is just my impression from Googling; I could be
Your basic questions have already been answered by others.
Now, I am going to recommend you DO NOT change the code.
1) It ain't broke, don't fix it.
2) While "end do" may be more elegant, I find it LESS USEFUL than
labelled CONTINUE to end DO loops.
a) you can always group the DO and the END DO when reading code
b) CYCLE and EXIT are limited to one up and all the way out, if
you have more than two levels of looping, only labels will allow
you to pop to specific intermediates higher than one up
3) writing DO ... END DO is easier. Use it for new code, if you want.
I don't. But that's my preference.
I know most of the clf regulars will disagree with me on this point.
This is not so much a right/wrong as a style/preference issue. I prefer
the added (to me) clarity of numbered/labelled DO loops. Other people
find END DO clearer. DO what works BEST FOR YOU.
BUT as an engineer, who writes a lot of code and reuses old code, I
must say my bottom line onf this is still "it ain't broke, don't fix it"
MHOO -- YMMV
(GOTOs considered harmful) considered harmful.