Fortran 2008: How are function return values returned?

Question

Is it possible in modern Fortran to return an array from a function with performance equivalent to having a subroutine fill an array passed as argument?

Consider e.g. as simple example

PROGRAM PRETURN 

  INTEGER :: C(5)
  C = FUNC()
  WRITE(*,*) C
  CALL SUB(C)
  WRITE(*,*) C

CONTAINS 

  FUNCTION FUNC() RESULT(X)
    INTEGER :: X(5)
    X = [1,2,3,4,5]
  END FUNCTION FUNC

  SUBROUTINE SUB(X)
    INTEGER :: X(5)
    X = [1,2,3,4,5]
  END SUBROUTINE SUB

END PROGRAM PRETURN

Here the line C = FUNC() would copy the values from the function return value, before discarding the returned array from the stack. The subroutine version CALL SUB(C) would fill C directly, avoiding the extra coping step and memory usage associated with the temporary array – but making usage in expresions like SUM(FUNC()) impossible.

If however, the compiler implementation chose to allocate all arrays on the heap, the return value could be assigned simply by changing the underlying pointer of C, resulting in equivalent performance between the two versions.*

Are such optimizations made by common compilers, or is there some other way to get function semantics without the performance overhead?

---

* It would be more apparent with allocatable arrays, but this would run into compiler-support issues. Intel fortran by default doesn't (re)allocate arrays upon assignment of a different-size array but allows the same effect by using an ALLOCATE(C, SOURCE=FUNC()) statement. Gfortran meanwhile does the automatic allocation on assignment but has a bug that prevents ALLOCATE statements where the shape is derived from the SOURCE argument and the fix hasn't been included in binary releases yet.

Answer 1

The Fortran standard is silent on the actual mechanism for implementing pretty much anything in the language. The semantics of the language are that the function result is completely evaluated before the assignment starts. If one passed the destination as the output then if the function didn't complete for some reason the variable might be partially modified. A compiler might be able to do enough overlap analysis to optimize this somewhat. I am pretty sure that Intel Fortran doesn't do this - the semantic restrictions are significant.

Your example is a toy program - the more interesting question is if there are production applications where such an optimization would be applicable and worthwhile.

I will comment that Intel Fortran will change its default behavior for assignments to allocatable arrays so that, as of version 17, the automatic reallocation will occur as specified by the standard.

Answer 2

I sometime have the same though. When I stop and think about it a moment, I realize that functions are good the way they are and subroutines are good the way they are too when it comes to fortran.

Imagine a minute that the capability is there and we have the following function:

function doThings(param) results(thing)
    integer :: thing
    integer, intent(in out) :: param
    ! Local variables
    integer :: genialUpdatedValue, onOfThePreviousResult
    ! some other declarations
    ! serious computation to do things
    ! and compute genialUpdatedValue and onOfThePreviousResult
    param = genialUpdatedValue
    thing = onOfThePreviousResult
end function doThings

And we have the following calls:

! some variables first
integer, parameter :: N_THINGS = 50 ! just love 50
integer :: myThing, myParam
integer, dimension(N_THINGS) :: moreThings
!
! Reading initial param from somewhere
! myParam now has a value
!
myThing = doThings(myParam)

That is definitely OK, what about the following

!
! Reading initial param from somewhere
! myParam now has a value
!
moreThing = doThings(myParam)

What is that going to give as result? Shall it be

integer :: i
do i = 1, N_THINGS
    moreThings(i) = doThings(myParam)
end do

or shall it be this one

integer :: i, thing
thing = doThings(myParam)
do i = 1, N_THINGS
    moreThings(i) = thing
end do

Remember that myParam gets changed by the function. One can argue that this is a simple case, but image that the result was not an integer but a user defined type with large array members.

If you think about it, you will definitely find some problems like those. Of course more restriction can be added here and there to allow that feature, and eventually, when we have enough demand, it will be implemented with the necessary restrictions. I hope that helps.