- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This could be a symptom of array over-run. If so, /check ought to help find it. Interprocedural optimizations increase sensitivity to such bugs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Try adding /warn:interface to your build and see what you get.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page