(j3.2006) interpretation F08/0089
Robert Corbett
robert.corbett
Fri Jul 26 21:53:12 EDT 2013
I voted for the proposed answer to F08/0089 in PL22.3 ballot #28.
Ian Harvey subsequently convinced me that the answers given for
questions Q1 and Q2 are wrong. He convinced me that the premise
on which those questions are based is false and that the proposed
edits are incorrect.
The QUESTION section of the proposed text of interpretation F08/0089
starts with
-------------------------------------------------------------------------
QUESTION:
Questions 1-3 use this module:
Module m200c2
Integer,Target :: x = 42
Contains
Function fx()
Integer,Pointer :: fx
fx => x
End Function
End Module
Q1. Consider this main program
Program q1
Use m200c2
Call test(x,fx()) ! The call.
Contains
Subroutine test(a,b)
Integer :: a,b
a = a*10 ! The assignment.
Print *,a,b
End Subroutine
End Program
According to Fortran 2003, "fx()" in the CALL statement is an
expression and not a variable, and has the value 42. It follows
that the assignment "a = a*10" is standard-conforming and does
not affect the value of B. Therefore this program prints
420 42
-----------------------------------------------------------------
The use of fx() in the call statement is an expression, not a
variable, according to the Fortran 2003 standard. The function
result of the function reference fx() is a data pointer that is
associated. The target of the data pointer is the variable x.
Clause 7.1.4.1p3 [123:39-124:3] of the Fortran 2003 standard
states
If a pointer appears as one of the following,
the associated target object is referenced:
(1) A primary in an intrinsic or defined operation,
(2) The <expr> of a parenthesized primary, or
(3) The only primary on the right-hand side of an
intrinsic assignment statement.
None of those cases apply. Therefore, the result of the function
reference fx() remains the data pointer, not the value of the target
object.
Clause 12.4.1.2p8 [269:20-22] of the Fortran 2003 standard
states
Except in references to intrinsic inquiry functions, if
the dummy argument is not a pointer and the
corresponding actual argument is a pointer, the actual
argument shall be associated with a target and the dummy
argument becomes argument associated with that target.
Therefore, the dummy argument b of the subroutine test becomes
argument associated with the variable x.
Because both dummy arguments of the subroutine test are argument
associated with the same variable and because the dummy argument
a is assigned a value, the program violates item (2) of
Clause 12.4.17p1 [275:1-11] of the Fortran 2003 standard.
Therefore, the program is does not conform to the requirements
of the Fortran 2003. Thus, the assertion that the program
conforms to the Fortran 2003 standard is false.
I ran the program myself using the latest release of Oracle
Solaris Studio Fortran, and I asked others to run the program
for me using other compilers. Oracle Solaris Studio Fortran,
NAG f95 5.1 and gfortran 4.1 wrote
420 42
as specified in question Q1. Recent releases of gfortran,
g95 0.94, pathf95 4.9.0, crayftn 8.1.8, pgf90 13.4, and
ifort 13.1.3.192 wrote
420 420
While some of these compiler might have implemented the
Fortran 2008 syntax and semantics, most of them have not.
In the case of Oracle Solaris Studio Fortran, the reason the
output is
420 42
is that the compiler is being clever. Even without the user
asking for optimization, it notices that the assignment to the
dummy argument a cannot affect the value of dummy argument b
if the program is standard conforming. It caches a local copy
of the value of dummy argument b and uses the cached value in
the PRINT statement. Anything that changes the compiler's
analysis, such as adding the TARGET attribute to a and b,
changes the output to
420 420
Bob Corbett
More information about the J3
mailing list