https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986
--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Sat, Jan 02, 2021 at 07:53:17PM +0000, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986 > > --- Comment #6 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #5) > > If the ENTRY statement is in a subroutine subprogram, an additional > > subroutine is defined by that subprogram. The name of the subroutine > > is entry-name. The dummy arguments of the subroutine are those > > specified in the ENTRY statement > > Well, I stumbled over the "additional subroutine". > > I assume that the "additional subroutine" wouldn't exist without the > containing > subprogram in the first place. Maybe a consultation of c.l.f. could help. > Not sure what you think clf will provide. Seems clear to me that subroutine volatile_test() integer, volatile :: va entry fun_a() return entry fun_b(va) call fun_c() return end subroutine volatile_test is equivalent subroutine volatile_test() integer, volatile :: va return call fun_c() return end subroutine volatile_test subroutine fun_a() integer, volatile :: va return call fun_c() return end subroutine fun_a() subroutine fun_b(va) integer, volatile :: va call fun_c() return end subroutine fun_b Here, only fun_b() requires an explicit interface if it is used in another scoping unit. AFAICT, a programmer is required to add interface subroutine fun_b(va) integer, volatile :: va end subroutine fun_b end interface to that scoping unit.
