Calling functions in OpenMP

[jirina]

I have a function defined like this:

[cpp]logical*4 function check_coordinates ( i, j, k )
integer*4 i, j, k
...
if ( ... ) then
  check_coordinates = .true.
else
  check_coordinates = .false.
endif
return
end[/cpp]

I am calling this function from within a parallel region:

[cpp]  integer*4 i, j, k, m, max_m
  logical*4 check_coordinates, match
  ...
*$omp parallel num_threads ( threads ) default ( shared )
*$omp&  firstprivate ( max_m, ... )
*$omp&  private ( m, match, i, j, k, ... )
*$omp do schedule(dynamic,3)
  do m=1,max_m
    ...
    match = check_coordinates ( i, j, k )
    ...
  end do
*$omp end do
*$omp end parallel[/cpp]

Should I have the function name check_coordinates listed in private for the correct functionality of the parallel code? When I tried to do so, I got a compiler error "error #6410: This name has not been declared as an array or a function. [CHECK_COORDINATES]".

[Steven_L_Intel1]

No - such a declaration would not be correct. You should not need to do anthing special here.

[jimdempseyatthecove]

The only consideration is your function local storage must be allocated of stack as opposed to as SAVE unless you expressly require SAVE variables.

INTEGER :: ITEMP(3)

May or may not be stack or SAVE depending on compile time options. To avoid such problems, I recommend you explicitly state the placement requiements

INTEGER, AMTOMATIC:: ITEMP(3)

This will avoid a rather lengthy bug hunt later on.

Jim Dempsey

[jirina]

I hope I am OK with the default settings I am using (Default Local Storage is the setting for Local Variable Storage, which should be AUTOMATIC if I understand IVF Help correctly).
I compile my project with /heap-arrays, so I hope I am not doing anything wrong. I know that I had a reason to use this option when converting my application (from Open Watcom Fortran) to IVF, but I don't remember the reason; maybe because of OpenMP (?).

[jimdempseyatthecove]

Relying on option switches to force local arrays to be stack (automatic) or not is, IMHO, a bad practice. Relying on option switches relating to placement has bitten me a few times, and for at least one of my consulting customers have bitten them (resulting in contracting with me for 3 days of work, plus flight, plus hotel, plus cab/limo) only to find majority of multi-threaded problems were due to being too lazy to add the recommended ", automatic".

In my not-so humble opinion, the FORTRAN language has the attribute SAVE. If the programmer wants SAVE then require SAVE, if the programmer wants stack local storage then omit SAVE.

This will break old code, therefor, add an option switch to cause undeclared placement to go SAVE.

Essentially, make the default behavior stack based.

my 2ct worth

Jim

[Steven_L_Intel1]

Enabling OpenMP causes all non-SAVE local variables to be stack-allocated.