(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


Questions 1-3 use this module:

   Module m200c2
     Integer,Target :: x = 42
     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.
     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 [123:39-124:3] of the Fortran 2003 standard

      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

Clause [269:20-22] of the Fortran 2003 standard

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