Rules for named DO constructs

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 8) ). 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

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.

Thanks Andy. You are correct on both counts.

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

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:

Quoted from JohnCampbell ... the number of possible values a label can take is limited to the depth of the do loop structure.

Can you explain what you're getting at here and what you see as the problem?

Andy

This bug has now been fixed.

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 'real8', 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 real10 and real16, depending on which compiler you use. I find most solutions that need better than real8 probably need an alternative approach. I could go on ...

I hope this makes my point about labels clearer !

John

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

Quoted from JohnCampbell 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 ...

... I think that's a good feature. Where else would you want a labelled EXIT to take you (I don't see how a labelled CYCLE statement can even be *interpreted * if the label is not confined to DOs that enclose it)? To my (perhaps over-pedantic) mind, the only reason for labelling a DO loop at all is to get proper control of EXIT with nested DOs. Certainly that's what I was up to recently. I suppose it also allows the DO to be the destination of a GOTO statement ... Would you value the ability to jump out of a DO loop to an arbitrary statement elsewhere? Eeek!

Quoted from JohnCampbell 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...

The more I think about this, the more the cost (if not danger) seems to outweigh the benefit to me, particularly if the label is allowed to have meaning outside the associated DO, as you seem to want. Doesn't it for example mean that you can't then use the same DO index in another DO later in the same routine?

Andy

Quoted from PaulLaidler This bug has now been fixed.

Paul,

It seems to have become unfixed again - at least with v5.10. I haven't got v5.21 installed, yet as company policy no longer permits me to DIY, and I thought I would wait awhile to ask nicely for it to be done, after the issue of v5.21 hot on the heels of v5.20.

Andy

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