Jumping from a CASE statement cascade to a program block down below (F90)

[TommyCee]

Consider this CASE statement cascade:

If (Title .eq. 'Some Character String ')THEN
Select Case(L)
CASE(1)
OPEN (11, FILE = 'File1.txt', STATUS = 'unknown')
GoTo 100
CASE(2)
OPEN (12, FILE = 'File2.txt', STATUS = 'unknown')
GoTo 100
CASE(3)
OPEN (13, FILE = 'File3.txt', STATUS = 'unknown')
GoTo 100
CASE(4)
OPEN (14, FILE = 'File4.txt', STATUS = 'unknown')
GoTo 100
CASE(5)
OPEN (15, FILE = 'File5.txt', STATUS = 'unknown')
GoTo 100
End Select

When the appropriate CASE is found, I want to jump below to a DO loop that startrs at line 100, e.g.,

100 DO 200, i = 1,n
{statements}

200 EndDo


On compile, I get this error message (it says "Warning" but believe me - it's a show-stopping ERROR):

Warning: A jump into a block from outside the block may have occurred. [100]

Is there no way to do this? Is this kind of "jumping" strictly verboten in F90?
Is there a slick work-around?

I earlier configured this as an if/then cascade and the "jumps" worked fine. Is there something unique about the CASE cascade?

Any help is appreciated.

TC

[TommyCee]

Oops! I'll answer my own question:

Yes, you CAN jump off from a CASE cascade. I presented an IF branch of the code that nests the CASE cascade (excerpt pasted above). At the bottom of a few more If/Then blocks, I accidentaly commented out my EndIf statement, so the IF/THEN block wasn't properly terminated. {Frankly, I'm surprised why the compiler didn't complain about that and directly point it out but it didn't.}

Anyway, I got my answer (the hard way, as usual).
I hack on ...
smile

[Steven_L_Intel1]

Can you show a complete program with the missing endif that doesn't get an error?

[mecej4]

I reconstructed this example based on what I read in this thread. The Intel compiler seems willing to allow a jump into an IF construct with only a warning.

[fortran]subroutine tsub()
   character(len=50) :: Title
   Integer :: I,j

   j = 100
   If (Title .eq. 'Some Character String ')THEN
      Select Case(L)
         CASE(1)
            OPEN (11, FILE = 'File1.txt', STATUS = 'unknown')
            GoTo 100
         CASE(2)
            OPEN (12, FILE = 'File2.txt', STATUS = 'unknown')
            GoTo 100
      End Select
      j = 0
   End If

   if(j.eq.100)Then
      j=j+50
!   EndIf      ! This is the missing EndIf
100   DO i = 1,n
          j=i*i+j
       EndDo
    return
    EndIf      ! misplaced EndIf, incorrect fix for syntax error reported earlier
    Return
end subroutine tsub
[/fortran]

[TommyCee]

In reply to Steve's request, I'm sorry to say that I vastly re-coded that program and so the original structure is lost. Sorry. But trust me, the error messaging was as I described. Sounds like you were more surpised than I was.

[TommyCee]

Actually, now that I pay better attention, MECEJ4 did a pretty good job in reconstructing what I presented. Except that when my program bailed out of one of the CASEs (GoTo100), 100 was not in an If/Then construct; it was just part of a series of program code. Not sure if that changes his interpretation but I just wanted to set it straight.

I revise MECEJ4's code as follows (this is a little more like what I had):

1. program OffMyCase
2. character(len=50)::Title
3. Integer::I, j , L
5. If(Title.eq.'SomeCharacterString')THEN
6. SelectCase(L)
7. CASE(1)
8. OPEN(11,FILE='File1.txt',STATUS='unknown')
9. GoTo100
10. CASE(2)
11. OPEN(12,FILE='File2.txt',STATUS='unknown')
12. GoTo100
13. EndSelect
14. EndIf <== THIS was the missing EndIf
16. 100DOi=1,n
17. j=i*i+j
18. EndDo
20. end program OffMyCase

[mecej4]

No, this version of the source, with the EndIf commented out, results in an error:

[bash]jmp.f90(5): error #6321: An unterminated block exists.
   If (Title .eq. 'Some Character String ')THEN
^
compilation aborted for jmp.f90 (code 1)
[/bash]

In this code, there is no reason for the compiler to issue the warning "A jump into a block from outside the block may have occurred".

I think that the compiler will not let code with an IF block without an EndIF go with just a warning.

[Steven_L_Intel1]

I have never seen a case where the compiler failed to diagnose a missing END IF.

In the tests I have constructed, a jump into a block gets a warning, not an error. Such jumps have always been illegal in Fortran (*), and even though the compiler does not give an error, the results of such a jump can be unpredictable. I remember coding the logic in the VAX Fortran compiler to detect such jumps.

(*) An exception is the Fortran 66 "Extended range of a DO loop" feature, where you could jump out of a DO loop and back into the samel level. This was removed in Fortran 77. Intel Fortran still allows this, again with a warning.

[TommyCee]

I went back and re-created that which I had discarded in the evolution of my program. I totally duplicated the problem I originally reported on this thread. I stand corrected and what I will say now validates what Steve & others have said: the Intel compiler will always diagnose (and flag as an error) a missing EndIf.

When my condition initially happened, the compiler (in the Build View area at the bottom of the IDE) listed a series of warnings pointing to the statement labels associated with the GoTo's in the CASE cascade. This was as I posted initially. What I failed to notice, listed way below, was the ever-familiar:

Error: An unterminated block exists.

I didn't see it! One question I do have (of the compiler) is:
Why not list the show-stopping errors FIRST?

It turns out that the warnings were just vague "contingencies" that, once the If/Then was properly terminated, went away.

Thanks for the attention to this and sorry for any confusion this post caused, but it was instructive (for me anyhow).

TC

[TimP]

I'm not a good example about habit-forming, but one of my habits for failed computation is to run "grep Error" on the build log. I wouldn't be capable of running even under Windows without installing grep. If you have a bias against that, there's always the ctrl-F search method for Windows text viewers.

[Steven_L_Intel1]

The missing ENDIF wasn't detected until the end of the program unit - errors come out in the order they are detected.

[TommyCee]

10-4, Steve. I guess you make a good point that validates the behavior seen (re: warning/error flagging sequence). Good call.