why does "-openmp" result different files for an OpenMP-free Fortran code?

[woshiwuxin]

Hi,

Sorry for the awkward title.

Basically, I have a piece of Fortran source code which contains no OpenMP directives (Its OpenMP-free). The compiler commands "ifort -openmp -c foo.f" and "ifort -c foo.f" produced different objects. Actually, the commands "ifort -openmp -S" and "ifort -S" could generate different assembly files. I was puzzled. Because the source code is OpenMP-free, the "-openmp" option should be expected to have no effect at all.

Moreover, if this code is compiled without an "-openmp" option (since it's completely OpenMP-free), and an analysis of the final binary with Inspector XE would reveal a data race in the beginning of the source file, e.g. subroutine foo(a, b, n). This subroutine has only local variables (no common blocks). I'm really confused...

Because this code is proprietary, I cannot post it here. Sorry!

Can anyone comment on this, or do you have the same experience?

[jimdempseyatthecove]

Adding the -openmp option informs the compiler that the functions and subroutines _may_ be called by OpenMP (from routine not in your compilation unit, eg a library with callbacks). With this option selected, the functions and subroutines are compiles as if the attribute recursive were in effect. (For OpenMP this would be re-enterant)

Jim Dempsey

[TimP]

Further to what Jim said, ifort does not perform dynamic allocation of local arrays unless one of the options with effect similar to RECURSIVE is in effect.  Any update in such arrays in more than 1 thread would be a race condition.

One of the recommended tests prior to turning on OpenMP is to verify correct working with RECURSIVE or equivalement compile option.

[woshiwuxin]

Thank you so much!

The data race can be solved by using either "-openmp" or "-recursive". Further inspections find its a problem of memory allocation of local _array_. The option "-auto" can solve this as well.

I can always find exports here :D