A Bug Occur when I call a pure subroutine in OpenMP

[志强_赵_]

1, The pure subroutine defined in a.f90, there is no OpenMP used here.

2, the OpenMP used in m.f90

when I compile the a.f90 like `ifort a.f90 -c -o a.f90` without -openmp

wrong result returned from the pure subroutine.

But, when I compile the a.f90 like `ifort -c -openmp -o a.f90`

correct result returned.

As I know, the pure subroutine is process safe. Why my subroutine return two kinds of results.

The a.f90 doesn't use OpenMP , why I shold compile it use -openmp

[志强_赵_]

I use ifort 13.0.0

[Steven_L_Intel1]

You will need to show us a complete test case with a small (if possible) source that shows the problem.

[jimdempseyatthecove]

>> `ifort a.f90 -c -o a.f90`

The above command line is producing an object file (a.o).

If this file is subsequently linked with a threaded program any local arrays contained within subroutines or functions within a.o will not be multi-threaded safe.

The default option is -auto-scalar, which means scalar variables are stored on stack (but not arrays). You can override this by using -auto or indirectly by using -openmp.

Jim Dempsey

[TimP]

As Jim pointed out, -openmp option could make the subroutine safe to execute in parallel (or re-entrant), as would adding RECURSIVE in the subroutine declaration.  This requires that the local arrays be correctly initialized; as it works for you, they may be OK.

[志强_赵_]

Tim Prince wrote:

As Jim pointed out, -openmp option could make the subroutine safe to execute in parallel (or re-entrant), as would adding RECURSIVE in the subroutine declaration.  This requires that the local arrays be correctly initialized; as it works for you, they may be OK.

Awesome, It's FIne

[志强_赵_]

jimdempseyatthecove wrote:

>> `ifort a.f90 -c -o a.f90`

The above command line is producing an object file (a.o).

If this file is subsequently linked with a threaded program any local arrays contained within subroutines or functions within a.o will not be multi-threaded safe.

The default option is -auto-scalar, which means scalar variables are stored on stack (but not arrays). You can override this by using -auto or indirectly by using -openmp.

Jim Dempsey

Thanks for your reply. Everything is Fine. But I still have a question.

-auto can set call variables AUTOMATIC which means each subprogram will have their own copy.

But if not, why the error occur.  If one thread has allocate memory for the variables in one subroutine, another thread can overwrite the memory directly? 

[TimP]

Yes, without -auto, all threads will share a single copy of the local arrays, and any modification creates a race condition.

[jimdempseyatthecove · Accepted solution]

>>-auto can set call variables AUTOMATIC which means each subprogram will have their own copy.

Maybe something is lost in translation.

To me, "call variables" are the arguments on the call statement and listed arguments on the subroutine statement. In Fortran-speak these are referred to as Dummy arguments. The subroutine scoped variables (those not dummy arguments) are the variables affected by the -auto, the dummy arguments are not affected by the -auto.

In Fortran without -auto

real :: vec(3)

is equivalent to C

static float vec[3];

And with -auto is equivalent to C

float vec[3];

When the vec[3] is defined inside a C function static produces a shared copy, whereas non-static (stack local) provides a private copy to the caller (thread and/or recursion level).

Jim Dempsey

[志强_赵_]

jimdempseyatthecove wrote:

>>-auto can set call variables AUTOMATIC which means each subprogram will have their own copy.

Maybe something is lost in translation.

To me, "call variables" are the arguments on the call statement and listed arguments on the subroutine statement. In Fortran-speak these are referred to as Dummy arguments. The subroutine scoped variables (those not dummy arguments) are the variables affected by the -auto, the dummy arguments are not affected by the -auto.

In Fortran without -auto

real :: vec(3)

is equivalent to C

static float vec[3];

And with -auto is equivalent to C

float vec[3];

When the vec[3] is defined inside a C function static produces a shared copy, whereas non-static (stack local) provides a private copy to the caller (thread and/or recursion level).

Jim Dempsey

Thanks so much. This is so magic. It's the first time for me to find the array is static default. You are so awesome. This problem is clear now.:)

[TimP]

The local array static default seems to be a "legacy relic" from long-ago DEC Fortran (which didn't have good support for threading).  There may have been some cases which would have run slower when the default of /Qsave was removed.  It may create enough confusion now that perhaps -auto ought to be considered for inclusion in -standard-semantics

[jimdempseyatthecove]

Tim,

You can add this option to the environment variable INTEL_PRE_FFLAGS and/or ifort.cfg

Changing it to standard-semantics might blindside users during updates. On the other hand it would benefit newbie C programmers from making posts like this thread.

Jim Dempsey

[Steven_L_Intel1]

Tim, as it happens, the Fortran standards committee recently voted to make RECURSIVE the default for all procedures in Fortran 2015, so,, eventually, that will indeed happen. My guess is that we'll just make it the normal default. After all, C has been dealing with this for years.

[jimdempseyatthecove]

Yea!!!