Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

do loop error

kageist
Beginner
1,081 Views
-I'm trying to figure out what this error message means:

error #6526: A branch to a do-term-shared-stmt has occurred from outside the range of the corresponding inner-shared-do-construct. [748]

-Here is the code I think it's talking about

!BEGINNING OF C MATRIX DELETIONS BY ROWS

ID77=0

IA=-M

DO 748 LK=1,3

IA=IA+M

DO 748 J=1,M

L=J+IA

DO 752 K=1,IDLT

IF (MTRXD(K)-J) 752,751,752

752 CONTINUE

GO TO 753

751 ID77=ID77+1

GO TO 748

753 JMID7=L-ID77

DO 748 I=1,N

IREC=I999(L,I,N1234)

READ (1'IREC) C

IREC=I999(JMID7,I,N1234)

WRITE (1'IREC) C

748 CONTINUE

-Any help would be appreciated.

0 Kudos
4 Replies
jparsly1
New Contributor I
1,081 Views

From the message, I'd say that it objects to having the "GO TO 748" statement
right before the "753 JMID7 = l - ID77" branch to the 748 CONTINUE that is shared by
several loops. It's doesn't like it because the GO TO 748 is outside of last of the "DO 748..." loops.

Probably the easiest way to fix this is to convert the innermost DO 748 loop into a DO/END DO pair.

Just change DO 748 I=1,N into DO I=1,N. Then add an END DO right before the 748 CONTINUE.

This must be pretty old code. Hardly anyone uses arithmetic IF statements anymore. A logical IF in a block construct would clean things up a bit.

The READ(1'IREC) and WRITE(1'IREC) statements are something I remember from one of the older IBM mainframe compilers. This will probably have to be rewritten into READ(1,rec=IREC) and
WRITE(1,rec=IREC). You might also have to get rid of old code for setting up the direct access file
(DEFINE FILE?) and replace it with an OPEN statement.

0 Kudos
TimP
Honored Contributor III
1,081 Views
Yes, this idiom of skipping a DO loop by jumping to the labeled continue at the end of the loop was a feature of certain IBM compilers prior to 30 years ago. I agree with jparsly's comments.
Not all compilers which allowed this would have treated it the same. Some might have compared whatever value happened to remain in I against the loop termination value N before deciding whether to repeat that loop.
Fortran 66 allowed re-entering a loop by GOTO but only in the case where that code is reached from within the loop, so this sort of extension became clearly non-standard-complian with Fortran 77. Part of the reason for forbidding it may have been that many compilers failed to diagnose it correctly.
0 Kudos
Steven_L_Intel1
Employee
1,081 Views
Note that it isn't the jumping to the end, by itself, that is the problem, it's the fact that there are two nested loops that share a terminating CONTINUE. To which loop does label 748 belong? It was ambiguous in Fortran 77 - Fortran 90 specified that in the case of shared termination, the labeled statement belonged to the innermost loop, thus the compiler's complaint.

Tim is referring to an odd feature called "extended range of a DO loop", and the DEC F77 compilers allowed you to do this, but the DEC F90 compilers (from which today's Intel Fortran is derived) do not.

Jumping to a loop's terminating statement is still legal. But in the case of shared termination (which is no longer standard), jumping from outside the innermost loop is not legal. The simple solution is to use a second CONTINUE for the outer loop, or use DO-END DO and the modern CYCLE or EXIT statements.
0 Kudos
kageist
Beginner
1,081 Views
Thank you so much to all three of you! I learned more than I was expecting. The loops make a lot more sense now. I wasn't sure what the arithmetic if statements were doing untiljparsley mentioned it and I looked it up. I have many different codes that are filled with arithmetic if statements. Now I know what all those mean!

I changed the code to jparsley's suggestion and now the code works.

Thanks again!
0 Kudos
Reply