public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "kargl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/61069] Gfortran allows functions to be called as subroutines when defined in a separate source file Date: Tue, 06 May 2014 11:30:00 -0000 [thread overview] Message-ID: <bug-61069-4-DBpNYVDxLt@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-61069-4@http.gcc.gnu.org/bugzilla/> 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.
next prev parent reply other threads:[~2014-05-06 11:30 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-61069-4@http.gcc.gnu.org/bugzilla/> 2014-05-05 22:33 ` dominiq at lps dot ens.fr 2014-05-05 23:30 ` tristanmoody at gmail dot com 2014-05-06 11:30 ` kargl at gcc dot gnu.org [this message] 2014-05-06 17:38 ` sgk at troutmask dot apl.washington.edu 2014-05-06 17:42 ` pinskia at gcc dot gnu.org 2014-05-06 18:17 ` tristanmoody at gmail dot com 2014-05-06 18:43 ` sgk at troutmask dot apl.washington.edu 2014-05-06 18:53 ` tristanmoody at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-61069-4-DBpNYVDxLt@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).