[all-commits] [llvm/llvm-project] b781a0: [flang] Allow labels on END statements.

[Peter Klausler via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: b781a04f6aff145f43b6f87c5b987159c2b64123
      https://github.com/llvm/llvm-project/commit/b781a04f6aff145f43b6f87c5b987159c2b64123
  Author: peter klausler <pklausler at nvidia.com>
  Date:   2020-11-11 (Wed, 11 Nov 2020)

  Changed paths:
    M flang/lib/Semantics/resolve-labels.cpp
    A flang/test/Semantics/label15.f90
    A flang/test/Semantics/label16.f90

  Log Message:
  -----------
  [flang] Allow labels on END statements.

F18 clause 5.3.3 explicitly allows labels on program unit END statements.
Label resolution code accounts for this for singleton program units,
but incorrectly generates an error for host subprograms with internal
subprograms.

   subroutine s(n)
      call s1(n)
      if (n == 0) goto 88 ! incorrect error
      print*, 's'
   contains
      subroutine s1(n)
         if (n == 0) goto 77 ! ok
         print*, 's1'
   77 end subroutine s1
   88 end

Label resolution code makes a sequential pass over an entire file to
collect label information for all subprograms, followed by a pass through
that information for semantics checks.  The problem is that END statements
may be separated from prior subprogram code by internal subprogram
definitions, so an END label can be associated with the wrong subprogram.

There are several ways to fix this.  Labels are always local to a
subprogram.  So the two separate passes over the entire file could probably
instead be interleaved to perform analysis on a subprogram as soon as the
end of the subprogram is reached, using a small stack.  The stack structure
would account for the "split" code case.  This might work.

It is possible that there is some not otherwise apparent advantage to
the current full-file pass design.  The parse tree has productions that
provide access to a subprogram END statement "in advance".  An alternative
is to access this information to solve the problem.  This PR implements
this latter option.

Differential revision: https://reviews.llvm.org/D91217