[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