[PATCH, fortran] PR 38507 -- goto to end do is legal.

[Steve Kargl]

On Sun, Dec 14, 2008 at 11:02:31PM +0100, Tobias Schlüter wrote:
> 
> >   program a
> >   integer i
> >   do i = 1, 3
> >      if (i == 2) goto 10
> >      print *, i
> >10 end do
> >   end 
> >
> Indeed, looking at the October 97 draft I read:
> 8.1.4.2 Range of the DO construct
> The range of a block DO construct is the do-block, which shall satisfy 
> the rules for blocks (8.1.1).  In particular, transfer of control to the 
> interior of such a block from outside the block is prohibited.  It is 
> permitted to branch to the end-do of a block DO construct only from 
> within the range of that DO construct.
> 
> ? which is in direct conflict with what I implemented.  I wonder what I 
> was thinking, as I even mentioned END DO as a problematic special case 
> in one of the original PRs.

OK.  It seems we agree that the above code is legal and the 
current warning about a delete feature should be removed
(via my patch).

> >program a
> >   integer i
> >   i = 1
> >   if (i == 1) then
> >     goto 10
> >     i = 2
> >10 end if 
> >   goto 20
> >   if (i == 2) then
> >      i = 3
> >20 end if
> >end program a
> >
> >REMOVE:kargl[216] gfc4x -o z k5.f90
> >k5.f90:6.12:
> >
> >     goto 10
> >           1
> >k5.f90:8.10:
> >
> >10 end if 
> >         2
> >Warning: Deleted feature: GOTO at (1) jumps to END of construct at (2)
> >
> >This is wrong.  The GOTO 10 jumps to the ENDIF of the block that
> >contains the GOTO.  This is explicitly allowed by the Standard.  On the
> >other hand, no warning is issued for the GOTO 20, which is outside of
> >the IF-THEN-ENDIF block with the labeled '20 END IF'.
> >
> >I've been unable to penetrate the logic of the bitmap stuff in 
> >resolve_branch, thus the cc to Tobi.
> 
> It is actually very simple: each block has a bitmap which is a set 
> saying which label numbers are in each block.  For each contained block 
> the valid labels for a GO TO (or ERR descriptor in I/O) are the union of 
> the labels reachable from the containing block and the labels inside the 
> block itself (i.e. the inclusive bitwise OR of the bitmaps).  Now in the 
> PRs you mentioned that END IF and END DO are handled differently, namely 
> END DO is part of the contained block, END IF is part of the containing 
> block.  If END IF were part of the contained block, then the error for 
> the deleted gotos were automatic.

I can't tell if you agree with me or disagree.  I claim in the above
the 'GOTO 10' is legal and does not invoke Annex B(2).  The portion
of the code with 'GOTO 20' is legal but invokes Annex B(2).  Your patch
for 18937 does the opposite.

-- 
Steve