From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-470350-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 2101 invoked by alias); 12 Dec 2014 07:00:24 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 2002 invoked by uid 48); 12 Dec 2014 07:00:18 -0000
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
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.4.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: Joost.VandeVondele at mat dot ethz.ch
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: tkoenig at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-38220-4-Dfmz3Ekjb0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-38220-4@http.gcc.gnu.org/bugzilla/>
References: <bug-38220-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-12/txt/msg01357.txt.bz2

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...