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.
