Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.

intent(out) behavior

Karanta__Antti
New Contributor I
1,408 Views

My colleague pointed out to me that the Fortran standard says the following of intent(out):

18 The INTENT (OUT) attribute for a nonpointer dummy argument specifies that it shall be defined
19 before a reference to the dummy argument is made within the procedure and any actual argument that
20 becomes associated with such a dummy argument shall be definable. On invocation of the procedure,
21 such a dummy argument becomes undefined except for components of an object of derived type for
22 which default initialization has been specified.


38 If a nonpointer dummy argument has INTENT (OUT) or INTENT (INOUT), the actual argument shall
39 be definable. If a dummy argument has INTENT (OUT), the corresponding actual argument becomes
40 undefined at the time the association is established, except for components of an object of derived type
41 for which default initialization has been specified.

My colleague's interpretation was that this indicates that the value becomes undefined at entry to the routine and if not assigned a value remais so even in the calling routine.

I have been assuming that if an intent(out) parameter is not assigned a value in a routine, it retains its previous value and ifort seems to work like this. Here's a trivial sample:

[fortran]subroutine nonmoduleroutine( x, setit )
  integer, intent(out) :: x
  logical, intent(in) :: setit

  if ( setit ) x = 1

end subroutine

module intentional

contains

subroutine moduleroutine( x, setit )
  integer, intent(out) :: x
  logical, intent(in) :: setit

  if ( setit ) x = 2

end subroutine

end module

program intent_test

  use intentional

  integer :: x

  x = 0

  call nonmoduleroutine( x, .false. )
  write ( *, '(I)' ) x

  call nonmoduleroutine( x, .true. )
  write ( *, '(I)' ) x

  call moduleroutine( x, .false. )
  write ( *, '(I)' ) x

  call moduleroutine( x, .true. )
  write ( *, '(I)' ) x

end program

[/fortran]
Which prints

0
1
1
2

as one would expect if the original variable retains its value if the output parameter is not written to.

This leads me to interpret that the standard really means that trying to read a value of an output parameter in the routine recieving the output parameter has an undefined result if the read is done prior to assigning to the said parameter in that routine. However, there is no effect on the recieving variable's value in the calling routine if no assignment is done in the called routine. Am I correct?

0 Kudos
1 Solution
IanH
Honored Contributor III
1,408 Views
Both, as per your colleague.

View solution in original post

0 Kudos
4 Replies
mecej4
Honored Contributor III
1,408 Views
In most cases where Fortran source code is in violation of the standard, the standard does not specify how the compiled code should behave. By definition, UNDEFINED covers the behavior that you prefer, or the behavior that your colleague prefers, or the behavior that code compiled by the Intel compiler exhibits, or anything else (such as your refrigerator playing the 1812 Overture).

You should not attempt to interpret the standard based on how non-conforming code behaves. The behavior exhibited by your program may change from compiler to compiler, and may be affected by your specific choice of compiler options, the OS version, etc.
0 Kudos
Karanta__Antti
New Contributor I
1,408 Views

I'd like to emphasize that my question was really that does the standard mean that the value of the dummy argument is undefined in the context of the routine conteining the intent(out) or also in the calling procedure after the call?

0 Kudos
IanH
Honored Contributor III
1,409 Views
Both, as per your colleague.
0 Kudos
Steven_L_Intel1
Employee
1,408 Views
I agree with Ian. The dummy argument, and any actual argument it is associated with, become undefined on entry to the procedure. Undefined does not mean that it changes value, only that the standard no longer specifies what the value should be. An exception is for allocatable arguments and allocatable components of dummy arguments - those are deallocated on entry.
0 Kudos
Reply