[Bug fortran/61069] Gfortran allows functions to be called as subroutines when defined in a separate source file

[Bug fortran/61069] Gfortran allows functions to be called as subroutines when defined in a separate source file

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61069

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Your code is invalid and the compiler can do anything. Note that if you type
bar as you should, gfortran complains:

! { dg-do compile }
program foo
  implicit none
  integer :: i, bar
  external bar, baz

  i = 0
  call bar(i)
!  print *, bar(i)
  call baz(i)
end program

gives

pr61069_3.f90:4.19:

  integer :: i, bar
                   1
Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'bar' at (1)
pr61069_3.f90:4.19:

  integer :: i, bar
                   1
pr61069_3.f90:8.13:

  call bar(i)
             2
Error: 'bar' at (1) has a type, which is not consistent with the CALL at (2)

[Bug fortran/61069] Gfortran allows functions to be called as subroutines when defined in a separate source file

[tristanmoody at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61069

--- Comment #2 from Tristan Moody <tristanmoody at gmail dot com> ---
Of course the code is invalid. That's the point. The compiler is
inconsistent about whether it will catch that fact. This invalid code could
easily show up, say, when refactoring a large code base, converting a
subroutine to a function, wherein a subroutine call gets missed. Since this
is a case of the compiler treating invalid code as valid and not the
reverse, a fix is low priority, if not unnecessary. I just think it should,
at the very least, be noted in the documentation.

For what it's worth, neither the Intel nor the Portland compilers detected
that the code was invalid, even when everything was in a single source file.
On May 5, 2014 5:33 PM, "dominiq at lps dot ens.fr" <
gcc-bugzilla@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61069
>
> --- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Your code is invalid and the compiler can do anything. Note that if you
> type
> bar as you should, gfortran complains:
>
> ! { dg-do compile }
> program foo
>   implicit none
>   integer :: i, bar
>   external bar, baz
>
>   i = 0
>   call bar(i)
> !  print *, bar(i)
>   call baz(i)
> end program
>
> gives
>
> pr61069_3.f90:4.19:
>
>   integer :: i, bar
>                    1
> Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'bar' at
> (1)
> pr61069_3.f90:4.19:
>
>   integer :: i, bar
>                    1
> pr61069_3.f90:8.13:
>
>   call bar(i)
>              2
> Error: 'bar' at (1) has a type, which is not consistent with the CALL at
> (2)
>
> --
> You are receiving this mail because:
> You reported the bug.
>

[Bug fortran/61069] Gfortran allows functions to be called as subroutines when defined in a separate source file

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61069

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |kargl at gcc dot gnu.org
         Resolution|---                         |INVALID

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Tristan Moody from comment #0)
> This might not be the easiest thing to fix, as (1) it appears that verifying
> the semantics of a function call happen on a per-source-file basis, and (2)
> there is no apparent way of marking a procedure as either a subroutine or a
> function once it has been translated to assembly or object code.

Yes, there is an apparent way, but one must learn the Fortran
language to use properly use it.

> When the main program and the two subprograms are all in the same file, the
> error is correctly caught by gfortran:

This happens because gfortran can build the INTERFACEs for
bar and baz.

> However, when the main program is a separate file from the two subprograms,
> (i.e. program foo in foo.f90, bar and baz in bar.f90, then compiled with
> "gfortran foo.f90 bar.f90" ), then compilation proceeds without issue and
> the resulting executable behaves as though bar() was called and its result
> discarded.  Filing this bug report as this non-standard behavior does not
> appear in any of the documentation I have seen.

When you compile the main program and the 2 subprogram as separate
files, each is valid fortran code.  The code in each file is standard
conforming.  There is no non-standard behavior.

Now, to address your problem.  There are two mechanism you can use to
fix the situation.  (1) Put bar() and baz() in a module and USE it; or,
(2) Use INTERFACE statements to *explicitly* tell the compiler about 
bar and baz. 


Your favorite reference on modern Fortran should include a discussion
on implicit and explicit interfaces.

[Bug fortran/61069] Gfortran allows functions to be called as subroutines when defined in a separate source file

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61069

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, May 06, 2014 at 03:41:13PM +0000, tristanmoody at gmail dot com wrote:
> 
> I concede this point: the standard only specifies that the compiler catch
> nonconforming code within individual program units -- it does not make any
> statement about how to handle when the nonconformance is specifically the
> relationship between program units.  That is why I would agree with a "wontfix"
> resolution.  Note 1.11 of the Fortran 2008 standard states that the compiler's
> documentation should state what additional forms and relationships it allows. 
> I would take that to include instances such as this where nonconforming,
> invalid code is accepted and executable.
> 

The Fortran code conforms to the Fortran standard!  Why do you continue to
claim that it is nonconforming invalid code.  What the linker does to 
the object code after the Fortran processor has created the three object
files is beyond the scope of the Fortran standard.

[Bug fortran/61069] Gfortran allows functions to be called as subroutines when defined in a separate source file

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61069

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |WONTFIX

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Closing as won't fix as it requires too much infrastructure including inside
the linker.

[Bug fortran/61069] Gfortran allows functions to be called as subroutines when defined in a separate source file

[tristanmoody at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61069

--- Comment #7 from Tristan Moody <tristanmoody at gmail dot com> ---
(In reply to Steve Kargl from comment #5)
> The Fortran code conforms to the Fortran standard!  Why do you continue to
> claim that it is nonconforming invalid code.  What the linker does to 
> the object code after the Fortran processor has created the three object
> files is beyond the scope of the Fortran standard.

Not to belabor the point, but that is simply not correct.  Using the Fortran
2008 standard for reference, that code violates syntax rule R1220, constraint
C1226, of clause 12.5.1. --

R1220 call-stmt is CALL procedure-designator [ ( [ actual-arg-spec-list ] ) ]
C1226 (R1220) The procedure-designator shall designate a subroutine.

This is not to be construed as an argument that it should be fixed -- I concur
with Andrew Pinski's rationale -- it just needs to be documented.  That's all.

[Bug fortran/61069] Gfortran allows functions to be called as subroutines when defined in a separate source file

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61069

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, May 06, 2014 at 06:17:42PM +0000, tristanmoody at gmail dot com wrote:
> (In reply to Steve Kargl from comment #5)
> > The Fortran code conforms to the Fortran standard!  Why do you continue to
> > claim that it is nonconforming invalid code.  What the linker does to 
> > the object code after the Fortran processor has created the three object
> > files is beyond the scope of the Fortran standard.
> 
> Not to belabor the point, but that is simply not correct.  Using the Fortran
> 2008 standard for reference, that code violates syntax rule R1220, constraint
> C1226, of clause 12.5.1. --
> 
> R1220 call-stmt is CALL procedure-designator [ ( [ actual-arg-spec-list ] ) ]
> C1226 (R1220) The procedure-designator shall designate a subroutine.
> 


  program foo
  integer i
  external bar, baz
  i=0
  call bar(i)
  call baz(i)
  end

This is standard conforming Fortran.  When gfortran compiles 
this code, there is no way for gfortran to know that bar
or baz is not a subroutine.  In fact, bar and baz may not have
been written when the main program is compiled.  It is the
programmer's responsibility to get the semantics right.

[Bug fortran/61069] Gfortran allows functions to be called as subroutines when defined in a separate source file

[tristanmoody at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61069

--- Comment #9 from Tristan Moody <tristanmoody at gmail dot com> ---
(In reply to Steve Kargl from comment #8)
>   program foo
>   integer i
>   external bar, baz
>   i=0
>   call bar(i)
>   call baz(i)
>   end
> 
> This is standard conforming Fortran.  When gfortran compiles 
> this code, there is no way for gfortran to know that bar
> or baz is not a subroutine.  In fact, bar and baz may not have
> been written when the main program is compiled.  It is the
> programmer's responsibility to get the semantics right.

That *program unit* is, by itself, standard conforming.  The program as a whole
is not.  You are correct that it is incumbent upon the programmer to get that
part right.  Clause 1.5 of the standard only specifies that the compiler verify
correctness at the program unit level.  The standard does not explicitly say
the compiler must verify correctness of the code at a holistic level.  Thus,
whether gfortran will know whether bar or baz is a subroutine is irrelevant to
the question of whether the program is conforming.  They are two different
issues.

It is, in my opinion, a weakness of the language itself, as it allows names to
be introduced into global scope with no way to identify what they are.  That
said, the bug is closed "wontfix," which is fine with me, and I will stop
polluting everyone else's inboxes.