Mr. Anderson mentioned that the 2015 release may have been tuned up for some usage with Windows gfortran. I verified that it works well with -g3 -gdwarf-2 as long as I don't add -fopenmp. I don't know whether those specific debug options may be the only ones which work; they aren't the normal ones for the shared libraries, and I didn't try to display source of library hotspots.
Perhaps not unexpectedly, as libgomp Windows is not at all compatible with libiomp5, and VTune 2015 has special hooks to current libiomp5, the analysis fails with the gnu OpenMP. VTune reports the .trace file is corrupted. I built libgomp along with gcc/gfortran myself with the default options.
I didn't test the alternate closed source equation.com OpenMP which is distributed in apparent violation of gcc GPL licensing.
I prepared a reproducer to post on an IPS issue, but that Intel site isn't accepting uploads and is scheduled for down times over the next 2 weeks. Maybe it will work again after those maintenance periods.
What analysis type did you use? Anyway - the application shouldn't crash under analysis so we need reproducers to look at this. Hope MrAnderson will be able to help with the reproducer transfer to the dev team.
Thanks & Regards, Dmitry
mingw (for gcc/g++ on Windwos*) compiler should be supported since VTune(TM) Amplifier 2013 Update 7, and it also should be supported in 2015 initial release I think.
I don't know about gfortran, but usually compiler option "-fopenmp" is necessary. It's better that you use linker option "-liomp5" if you installed Intel? Fortran compler (ifort).
In my experience, cygwin and mingw compilers have much the same degree of compatibility with VTune. If you're telling me that gfortran and cygwin aren't intentionally supported, I can believe it, but to me it's a significant advantage when VTune works with cygwin. You may be missing a significant market if you don't encourage use of VTune with gfortran for linux even though it happens to work well (maybe with -liomp5 as you suggested).
gcc with OpenMP is built for Windows with configure options --enable-libgomp --enable-threads=posix (which aren't the default). Those options are used in every gcc I've seen which supports OpenMP. Again, I discount the equation.com mingw fork which violates gcc licensing. Presumably all Intel employees have received training abut GPL etc. Needless (?) to say, since libgomp remains dependent on posix libraries on Windows, as on linux, and libiomp5 for Windows handles Microsoft OpenMP calls but not libgomp ones, I've not seen any suggestions on how gcc or gfortran could be linked with libiomp5 for Windows.
It may be that someone has linked a mingw build (not using OpenMP) against MKL parallel, which would use libiomp5.dll. I thought the removal of MKL as a separate product was intended to discourage this.
Could it be that the Intel testing of VTune was against a mingw compiler not built with libgomp compatibility?
If it's clear that none of gfortran, cygwin, or gcc OpenMP for Windows are intended to be supported by VTune, there's no point in my returning to premier.intel.com to see if the upload site has come back on line.
The only thing that is "clear" is this, unless we specifically list something as supported in the Release Notes, we are not testing against it (and, even then, we don't tested every release against every supported OS, tool set, etc.). As long as build tools produce compatible debug information in a format recognized by the VTune Amplifier, it should work. If you have a specific case that does not work, then you should do as you have and submit an issue at Intel Premier Support. We will investigate and, if a problem exists, determine the priority of fixing it in light of all our other activities.
Thanks for bringing this particular issue to our attention. :)
Thanks, then I'll check the IPS site from time to time to see if it starts accepting new issues again. I'll upldad the .exe and .dlls as well as source code. The case can be built equally well with any OpenMP Fortran, and of course it works fine with ifort OpenMP.
If it does, will you want an issue which demonstrates just mingw-64 gcc with OpenMP? I've no doubt that all these work without OpenMP.