Writing internel Variables to file -> Warning: An Array was temporarry created

Writing internel Variables to file -> Warning: An Array was temporarry created

I am dealing with Fortran 77 legacy code and have therefore written a debugging routine with which I can save the timehistory of arbitrary internal Variables to a file:

      module M_checkup




      ! write new variable to output array
      subroutine writecheck(value,title,line,anzahl_o,mode)

      implicit none

      real,intent(in) :: value(:)
      character(*),dimension(*),intent(in) :: title
      integer,intent(in) ::line
      integer,optional,intent(in) :: anzahl_o
      character(*),optional :: mode


      end subroutine writecheck

      end module M_checkup

This routine matches the string(s) of "title" to an already existing title-list and expands the title-list if "title" is not already in there. The position of "title" in the title-list is extracted and "value" is written to an existing value-list at the corresponding position and "line". At the end of the program these title- and value-lists are written to a text file for further analysis via matlab, etc. Because sometimes you want to save whole arrays or multiple values at once the routine has to cope with single values as well as contiguous and non-contigous arrays, which is the reason for using assumed-size arrays.

Exemplary usage in Code:

       subroutine step

       use M_checkup,only:writecheck

       implicit none


       call writecheck((FORCER(1:6)),['S4_FX_ROT',
     F                                   'S4_FY_ROT',
     F                                   'S4_FZ_ROT',
     F                                   'S4_MX_ROT',
     F                                   'S4_MY_ROT',
     F                                   'S4_MZ_ROT'],
     F                                   JNBL,6)
        call writecheck([SPCKDATA%FSTEU(IB),(ZMR(19,JNBL))],
     F                      ['SPCK_FSTEU','S4_FSTEU__'],JNBL,2)

        call writecheck((/S4DATA%HUBFORCNONROT%FX/),'SPCK_FX_NR',JNBL,1)


       end subroutine step

As you can see, in the first example, the arguments are part of an existing array and therefore are contiguously represented in the memory. In the second example the arguments passed to the subroutine are from different variables and therefore are not-contiguously. As I understand it, example two is the reason the compiler throws the following warnings:

forrtl: warning (402): fort: (1): In call to WRITECHECK, an array temporary was created for argument #2

forrtl: warning (402): fort: (1): In call to I/O Write routine, an array temporary was created for argument #1

In my opinion the compiler seems to be warning me because the "title" and "value" arrays get copied because they are non-contiguous.

Because this routine gets called a lot of times the printout slows down the program quite a lot. Therefore I'd like to get rid of the warning without disabling the corresponding compiler option. I suspect, that I'm using assumed-size arrays wrong, because to I think I don't understand/ missunderstand the whole concept.

The responsible warnings are only enabled in the debug build-type and the corresponding routine is only used for debugging. Because iot that there is no problem with the implied performance loss due to the array copying. Therefore I have disabled the corresponding warning (/check:noarg_temp_created) for the moment. My question is:


Is there a way to improve this debugging routine so that the warning would not show?

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

The warning is because the arrays you pass are created in expressions. You can avoid the warning by using a variable to store the created array before passing it, but it needs a lot of coding, unless someone can shorten it !  I complained about this warning before since it is obvious the coder wanted a temporary array to be created in this case.

real, allocatable :: realTemp(:)

	character(:), allocatable :: stringTemp(:)

	allocate(realTemp(2), stingTemp(2))

	realTemp = [SPCKDATA%FSTEU(IB),(ZMR(19,JNBL))]

	stringTemp = ['SPCK_FSTEU','S4_FSTEU__']

	call writecheck(realTemp, stringTemp, JNBL,2)

	deallocate(realTemp, stringTemp)

In my case the point is exactly to provide the user/ programmer with a 1-liner to store certain variables and write their time history. Writing to separate arrays just before the call to writecheck is therefore not an option in my case.

Thanks anyways for the suggestion.


You can compile your report source file/module without the option to warn for array temporaries. In the solution explorer for VS, right-click on the file with the report, choose properties, then disable the warn for array temporaries option. This will disable for that source file only. Note, you can do the same thing for different options, like turning off optimizations for debugging one of hundreds of files (others with full optimizations).

Jim Dempsey 



thank you very much for your suggestion. I will look into this option and see if I can incorporate this into our cmake build routine for automation.

Because we are developing on Windows and Linux it is usually better (and simpler) to keep the build options consistent for all source files. Also not everybody uses VS and I therefore have to find out if it is possible to set/ unset certain options for different files accross all compilers, IDEs and their combinations.

Therefore I prefer a modification of the routine to keep everything consistent. I also wouldn't mind to rewrite the routine, for example if I'm using assumed-size arrays the wrong way, but I have not found an easy way to do it, yet.

The requirements for the debugging routine would be:

  • store variable/ variables for debugging via 1-line command/ call to subroutine
  • variables to store can be single variables or partial/ whole arrays while using the same 1-line command/ call
  • arrays passed may often be not-contiguous
  • save all variables and their time history during execution
  • write all saved variables to a (text-)file at the end of the program

Leave a Comment

Please sign in to add a comment. Not a member? Join today