forums.silverfrost.com

[sparge]

I have just spent a couple of hours refactoring a load of code by using the option to name DO loops (never done this before, bit newfangled for my taste ). I found that there seemed to be inconsistencies between the rules as outlined in the help file and as implemented during compilation. So I had a look at Metcalf & Reid.

If we take M&R as gospel, then both the help file and FTN95 need tightening up a bit. According to M&R, the only rule for naming a DO construct is: The DO and END DO statements must either both bear the same name, or both be unnamed" (p.67).

Relative to this, the help file commits both an error of commission and (as a result) an error of omission. It says: "If a DO construct is named then the same name, must be appended to EXIT and CYCLE" (wrong). What it should say is "If a DO construct is named then the same name must be appended to the matching END DO".

More importantly, FTN95 acts incorrectly. The following code compiles without error:

program donominator
main: do
exit
end do
stop
end program donominator

[JohnCampbell]

I have long been a critic of the fortran 90+ standard on do loop labels. I thing that the use of labels should be much more flexible in it's implementaion, as the number of possible values a label can take is limited to the depth of the do loop structure.
I also think that do loop counters should also be useable as implied labels. making the code more readable. For example, the following code is clear to me ! Where this implied label is a problem with the standard, then the code example is poorly written.

x = 0
do i = 1,n
do j = 1,m
if (aa(j) == j) cycle j
if (aa(j) == i) cycle i
x = x + 1
end do
end do

As for the use of labels, I rarely must use them so avoid the problem.

If Salford is taking a more flexible approach to DO loop labels, they have my vote.

[PaulLaidler]

Thanks Andy. You are correct on both counts.

We will aim to have these fixed for the next release.

[sparge]

John,

I don't know what to make of your suggestion and associated pseudo-code. I'd agree with you that the intention is clear, but it would represent quite a departure from the standard. Certainly the error messages that FTN95 generates for this code indicate deep problems with its attempt to comprehend the syntax.

The thing I really didn't understand in your post was this:

[PaulLaidler]

This bug has now been fixed.

[JohnCampbell]

Andy,

My understanding is that do loop labels can and need only be used on CYCLE or EXIT statements of nested do loops. If you are, say 3 levels down into a do loop, there are only 2 to 3 possible destinations that labelled CYCLE or EXIT can take you. ( the unlabelled imply the inner loop )

The label has no meaning outside the do loop it names, although I don't think you can use the same label elsewhere in a subroutine or function, making the label selected very limited in it's application. When considering the pre-90 style do loops, with counters, allowing the counter to be used as a label would have made better use of meaningful labels.

When I started labelling do loops, a long time ago, I quickly ran out of labels that improved the readability of the code. It's just one thing in the F90+ standard that has always annoyed me... That and not providing more recognition for common kind syntax, such as "real*8", which is such a concise and clear method of describing the expected precision, it should be recommended. If you ever converted old (possibly) Control Data Fortran of the 70's to mini or PC, you'd understand what I mean. The use of precision definition, such as "selected_real_kind" hides the precision options, which are usually very limited. The only benefit I've found is that it provides the opportunity to switch between real*10 and real*16, depending on which compiler you use. I find most solutions that need better than real*8 probably need an alternative approach. I could go on ...

I hope this makes my point about labels clearer !

John

[sparge]

Yes, much clearer! So now I don't understand the perceived limitation.

[sparge]

[PaulLaidler]

I think that it must have been fixed after 5.10.
It is fixed the current release.