public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "Joost.VandeVondele at mat dot ethz.ch" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/38220] C_LOC intrinsic non-pure and without explicit interface Date: Fri, 12 Dec 2014 07:00:00 -0000 [thread overview] Message-ID: <bug-38220-4-Dfmz3Ekjb0@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-38220-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38220 Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |burnus at gcc dot gnu.org, | |Joost.VandeVondele at mat dot ethz | |.ch Resolution|FIXED |--- --- Comment #6 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> --- I believe this introduced a regression, C_LOC is not pure. Just quoting from here https://software.intel.com/en-us/forums/topic/269061 The "standard intrinsic procedures" are those listed in section 13.7 of F2003. Procedures in intrinsic modules are not included. I happen to be writing this from a meeting of the Fortran standards committee (J3) and posed this question - the response from one member was "because we forgot to issue the Ivory Soap certificates". None of the procedures in ISO_C_BINDING are pure. The example why this restriction is a good idea (inspired by PR64247) is the fact that if it where, any pure procedure could return different results even if the variables have the same value (as opposed to address): ! ! are functions containing C_LOC pure ? ! MODULE M1 CONTAINS PURE INTEGER*8 FUNCTION F(a) RESULT(I) USE ISO_C_BINDING, ONLY: C_LOC INTEGER*8, INTENT(IN), TARGET :: a I=TRANSFER(C_LOC(a),I) END FUNCTION END MODULE M1 PROGRAM TEST USE M1 INTEGER*8 :: i,ri INTEGER*8 :: j,rj i=4 ; j=4 ri=F(i) rj=F(j) IF (ri.NE.rj) CALL ABORT() END PROGRAM ifort rejects this code, gfortran and cft compile but trigger the runtime abort, pgf90 compiles and runs without abort. CCing Tobias as he approved the patch...
next parent reply other threads:[~2014-12-12 7:00 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-38220-4@http.gcc.gnu.org/bugzilla/> 2014-12-12 7:00 ` Joost.VandeVondele at mat dot ethz.ch [this message] 2015-05-16 6:08 ` tkoenig at gcc dot gnu.org 2023-03-15 11:03 ` jeff.science at gmail dot com 2023-03-15 20:45 ` anlauf at gcc dot gnu.org 2023-03-16 20:07 ` anlauf at gcc dot gnu.org 2008-11-21 22:03 [Bug fortran/38220] New: " dfranke at gcc dot gnu dot org 2008-12-09 20:31 ` [Bug fortran/38220] " dfranke at gcc dot gnu dot org 2008-12-09 20:51 ` dfranke at gcc dot gnu dot org 2009-01-06 13:06 ` tkoenig at gcc dot gnu dot org 2009-01-06 23:03 ` tkoenig at gcc dot gnu dot org 2009-01-06 23:05 ` tkoenig at gcc dot gnu dot org
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-38220-4-Dfmz3Ekjb0@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).