Effect of \Qipo on simulation results

[Koenebaas]

I am buidling a 64-bit DLL application with a lot of different f90 source files and compiling it with interprocedural optimization by specifying the /Qipo option. I am making use of the Intel® Parallel Studio XE 2017 Update 7 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio* 2013, Version 17.0.0053.12, Copyright © 2002-2017 Intel Corporation. My OS is Windows 10 enterprise 10.0.17763 Build 17763.

The full list of compiler options is as follows:
/nologo /O3 /Qipo /fpp /Qopenmp /module:"x64\Release\\" /object:"x64\Release\\" /Fd"x64\Release\vc120.pdb" /libs:static /threads /c

Now I found that adding the /Qipo option results in totally different (and wrong) results in comparison to running the same code without this compiler option. 

Any clue what is going on and how to resolve this (I would like to use the /Qipo option)?

[TimP]

This could be a symptom of array over-run.  If so, /check ought to help find it.  Interprocedural optimizations increase sensitivity to such bugs.

[Koenebaas]

Thanks a lot for your suggestion. After compiling with the /check option, running this code was unfortunately very slow and I was not able to get passed the first part of the code in hours, while the problem occurs in a later part. However I had a better look at the code history and found out after which source code modification I ran into differences when using the /Qipo option. I found that adding a new argument to a subroutine which already contained many arguments (several double precision scalars, vectors and matrices) was causing the problem. After making a separate new subroutine for passsing this particular variable, compiling the code with /Qipo and running it gave me the desired results again. Problem solved it seems but I am not sure what exactly has caused the problem, does my description indeed point at an arrray over-run? What should I have done to prevent this from happening (and can help me from encountering this issue in the future again)? As I mentioned the /check option did not really point me in the right direction unfortunately..

[Steve_Lionel]

Try adding /warn:interface to your build and see what you get.

[Koenebaas]

Sorry for the late update. Compiling with this option does not provide any extra warning in the buildlog as far as I can see. So although I found a workaround to the direct problem I am still a bit puzzled why there were no signs for me to detect this bug. Perhaps I should let it go as I am unable to provide the full source

[jimdempseyatthecove]

Koenebaas,

Compile the entire application except for the suspected subroutine (and extra argument) with the options that produce the error (quickly)...
but compile the source with the problem-some subroutine with the additional option of to perform run-time checks. This will only slow down when in the subroutine and may get your program to reach the error point in a reasonable time.

Jim Dempsey