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

Tobias Schlüter tobias.schlueter@physik.uni-muenchen.de
Mon Dec 15 10:14:00 GMT 2008


Steve Kargl wrote:
>>> 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.

Yes, I agree.  I was trying to point out a way of doing this: move the 
NOP representing the END IF inside the IF-block.  reachable_labels() 
also takes note of the last statement in a block, again mentioning END 
DOs, maybe that plays a role as well.

I'll have a look at this stuff tonight, Steve.  Maybe it's best if I 
clean up my mess myself.

Cheers,
- Tobi



More information about the Gcc-patches mailing list