Using -openmp and the effect of -auto in preparing a serial code to use OPenMP

[Jack_S_]

Hi all,

I have a large serial code (>15k line of code) with COMMONs blocks. I wanted to start transffering some time consuming loops to work under OpneMP parallelism. After reading some different posts in Intel's forums (i.e.:https://software.intel.com/en-us/forums/topic/279757), I decided to prepare first my code for OpenMP by adding the -auto compiler option to my set of flgas.

I'm getting different results. I'm aware to the dafult -openmp which sets also -auto. My question is - how to intial local variables / arrays in a robust way, including the COMMON blocks (at the begining of the code) to get the very same results only by adding the -auto.

The following step would be using -openmp flag / without any caluases for now - only to verify that the defualt behavior is not messing my calculations.

Thanks for any detailed insight that you can provide.

Jack.   

[Steven_L_Intel1]

COMMON blocks aren't affected by -auto - they are always statically allocated. As you probably know, static global data such as COMMON can interfere with parallelization.

Your problem is more likely to be with non-COMMON local arrays in subroutines, as without -auto these are static but with -auto they are stack allocated. You will need to be sure these are defined before their values are used.

[Jack_S_]

@Steve - Thanks very much for the rapid and useful replay.

Just to make sure, how the local arrays/scalars behave if not defined before usage when allocated to the stack ? 

Thanks again,

Jack.

[Steven_L_Intel1]

Any variable that is not defined before use has an undefined value. If the variable is statically allocated, which by default will include arrays, character and derived type), then usually you'll get zero but this is not guaranteed. Anything allocated to the stack or register will have an unpredictable value. Programs that assume zero initial values are incorrect.

I will mention that Intel Inspector XE can detect memory problems at runtime including threading errors such as inappropriate use of global variables.

[Jack_S_]

Thanks Steve !

I will try the Intel Inspector XE in that relation.

Jack.

[Jack_S_]

Steve and all,

A foolowup  - after reading  this : https://software.intel.com/en-us/articles/checking-for-unitialized-variables-using-init-compiler-flag , and finding the -init option of the Composer XE 2015 - is it safe to use signaling NaNs as "global" tracer of all local, IMPLICITLY saved undefined floating point variables, i.e., all local variable except COMMONs ? (I would still may have problems with automatic-arrays ...)

Thanks for any of your comments,

Jack. 

[Steven_L_Intel1]

In version 15, -init applies to statically allocated variables only. (This will change in the next major release.) So it won't affect most local variables. Of course, -init snan applies to real and complex types only.

[Jack_S_]

@ Steve - Thanks.

To whom is interested in solving this systemically across a very large code - Intel Inspector XE (2015 in my case) is highly recommended.

Thanks for the advice Steve, its interesting to see if it will catch every single bad memory accesses.

Regards, 

Jack.