Effect of OpenMP and other compiler options

[Arjen_Markus]

In one of our programs we use the OpenMP option together with several other options to make sure that local variables in subroutines are not shared among two or more instances of the same routine. This worked fine as long as we were careful enough to add the options to all relevant source files in the Visual Studio projects. Recently we started using CMake to generate the project files and solution on Windows and equivalent make files on Linux, so that we need to maintain a single set of build files only. So far so good.

What did not go right is that not all files that required the various options indeed were compiled that way. And that led us to checking what these options actually do. SO here goes - mind you, this is with Intel Fortran oneAPI.

The flags are -Qopenmp, -reentrancy:threaded and -Qauto.

Here are my questions:

• The default local storage option in Visual Studio (data: Local Variable Storage) appears not to be accompanied by a specific compiler option. So: what is the effect of this?
• Is there a drawback to specifying -Qauto for all source files by default, so that we will not forget when a new source file is added?
• Is the combination -reentrancy:threaded and -Qauto useful or is -reentrancy:threaded enough to achieve the effect that local variables in a subroutine are not shared between instances of that routine? (My guess is that it is enough to use -reentrancy:threaded).
• The help information on both Windows and Linux suggests that these options are not actually required, but the analysis of a failure of the program in one particular use case indicates that we do not these options (my colleague still needs to confirm that the run succeeds with these options in place, but the debugger showed suspicious behaviour that is compatible with non-reentrancy).

[andrew_4619]

Qauto has been in my default options for many years. The only "drawback" is if you have an old program that relives on locals being saved or doesn't initialise properly.  One of my reasons for adopting this option was to flush out such bugs. I think in the latest Intel compilers it is maybe the default option anyway as isn't recursion a default also? 

[Arjen_Markus]

No, I tried that, if you want it, you must specify -standard-semantics or -assume:recursion (I tested this by using a subroutine that called itself without the recursive attribute).

[andrew_4619]

Ah OK -standard-semantics is one of my std options  and if you drill into that it implies quite of lot of different things.