Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28457 Discussions

Run-time errors after upgrading to new compiler versions

vikramb
Beginner
243 Views

We have a code that was being built using version 12.1 and VS 2010. After upgrading to version 15.0 compiler (update 6) and VS 2013, we have been experiencing strange runtime errors in code locations that was running fine before. The failure has always been in Release mode (Debug mode does not have these errors). Also the error is due to a intent IN integer being modified. This argument is used to access an array component of a derived type. The subroutine being called is in a FORTRAN DLL and the subroutine is being called from a FORTRAN compiled executable (VC++ code is not involved). Also the bug goes away sometimes when a print statement is added at certain location in the subroutine but then fails (access violation) at some other subroutine due to a intent IN double precision being read.

Unfortunately I have not been able to reproduce this behavior in a simple test case. Any hints to diagnose what the issue is will be helpful. The errors happen both with /O1 and /O2 optimization flags.

0 Kudos
2 Replies
mecej4
Honored Contributor III
243 Views

Try the compiler option /assume:dummy_aliases . If it makes the error go away, you can narrow down the location by using it only for one subprogram at a time. If you do have aliased arguments, you can explore ways of eliminating the aliasing.

0 Kudos
vikramb
Beginner
243 Views

Thanks mecej4. That did not work. However I posted the issue with Intel premier support. The source of the problem was two derived types (with slightly different definition) in two different modules having the same name. The only reason I can think is that the caller and callee subroutines started using different definitions when I upgraded compiler versions. Why this wasn't an issue with older compiler is not clear. I would have to trace all the 'USE' statements to find out that out. That was bad coding but it has been lurking in the code seemingly forever.

0 Kudos
Reply