Offload compiler (and Linker/Librarian) option docs

[jimdempseyatthecove]

Using Intel Fortran or Intel C++ documentation tells you how to pass on options to the offload compiler, linker, etc... components, but it does not list the options available for each component. Nor does it have a link or other indication as to were to locate the documents. Can someone point me in the direction of these documents (and can the user documentation be updated to contain this information and/or links to this information).

Jim Dempsey

[Kevin_D_Intel]

The options available are the same as listed in the User Guide for the host compiler/linker. Where the option is not available you will see an indication in the Architecture Restrictions. For example, https://software.intel.com/en-us/node/581750

[Frances_R_Intel]

And for those who don't know where to find the User Guide - at the top of this page or any software.intel.com page, under Tools->Resources->Documentation (I don't know why it is under Tools) then under Filter->Products, select the Fortran or C++ compiler as desired. The list of documents will shorten to a couple pages and the User Guide will be somewhere near the top.

Jim, can you tell us what page you were looking at the raised the question in your mind? Was it something like Displaying Options Passed to Offload Compilation or something like Wl? I suspect you already know this but if you see something like Wl, when it says -Wl,option1,option2,etc., those options are what you see if you do 'man ld' (or 'man as' in the case of Wa, or 'man cpp' in the case of Wp).

[jimdempseyatthecove]

Thanks Kevin and Frances. My issue is I am programming from a Windows environment, using IVF (PS XE Pro 16 update 1).

Intel Fortran Compiler 16...Help | Index | offload compilation

Then under there, none of the 7 sub-topics has a list of the available options.

(Similar issue with the Intel C++)

I stumbled upon this because I wanted to VTune (VS 2013 integration). While I could make the run and get results, none of the symbols inside the .so generated inside my .DLL were available. I assumed that the compiler and/or linker and/or librarian were stripping (or not generating) the debug symbol tables. Trying to locate these options from the Host language documentation (IVF) is problematic.

If you have information on how to enable the symbolic information from an .so generated for a .dll on Windows I'd appreciate it. (I also set the directories if VTune for the binary and source folders to no avail).

I do see this warning message

1>ifort: warning #10362: Environment configuration problem encountered.  Please check for proper MPSS installation and environment setup.

MPSS 3.6-windows is installed (and reinstalled). The offload region runs, but I cannot get VTune to find (use) the symbol tables.

I posted an issue on Premier Support, and haven't received an update.

Do you have a sample of the complete environment variable settings (and/or) file dependencies that might cause this warning message?

It would be nice if in addition to "Environment configuration problem encountered" it would also report what specifically was the issue (e.g. MIC_FooBar not defined).

Jim Dempsey

[TimP]

I would expect an option such as -debug inline-debuginfo in compile and link steps to be sufficient. In vtune it's necessary to set all source and binary search paths to include objects and libraries on the host side (even those which have copies on coprocessor for running).

[jimdempseyatthecove]

1>ifort: command line error: Unrecognized keyword 'inline-debuginfo' for option '-debug'

I would expect when you build a Release build with full debug information (specified in the Windows VS properties) that the appropriate options to the offload compiler and linker would receive the appropriate options.

Jim

[Ravi_N_Intel]

Use inline-debug-info

On windows there are some options which are pushed/used to the MIC compilation and some are not due to a equivalent not available on Linux or mapping to from WIndows to LInux may not be easy.  Would a list of options that are pushed/used from Windows command to MIC compilation help?

[jimdempseyatthecove]

The extra - corrected the warning message about inline-debuginfo. Thanks.

It did not correct (explain) the warning #10362.

>> Would a list of options that are pushed/used from Windows command to MIC compilation help?

It would help if it were easily findable in the documentation.

Jim Dempsey

[Ravi_N_Intel]

I assume you are using MPSS 3.6 first release.  There is a know problem with it and you will see this diagnostic.  Should be fixed in the next release.

Reason for warning:  The compiler tries to find the default gcc header path and the compiler generates the warning not finding it at  certain location, uses an alternate location.

Regarding the command line options we will update the documentation.

[jimdempseyatthecove]

After building with the -debug inline-debug-info in the Additional Options for MIC Offload Compiler, and Additional Options for MIC Offload Linker (Release Build)

The resultant binary runs OK from the Debug | Start Debugging and Debug | Start Without Debugging, however when starting via the Amplifier I get

The application crashes

.AND,

It appears to have a null file name for debugging.

Jim Dempsey

[jimdempseyatthecove]

In C:\Program Files\Intel\MPSS\k1om-mpss-linux\boot there is a file named vmlinux-2.6.38.8+mpss3.6

how this migrates into /usr/lib/debug/lib/modules/2.6.38+mpss3.6 as filename vmlinux I do not know.

In C:\Program Files\Intel\MPSS\filesystem\common\usr\ there are folders bin and lib64 but no lib/debug/lib/modules/2.6.38+mpss3.6

I assume this is supposed to happen auto-magically for offloads.

Jim Dempsey

[jimdempseyatthecove]

Additional information. While the Release build Amplifier run crashed with allocation error (in offload allocation), the Debug build manages to run. I let it run to collect data, then stopped the run. This is what I observe from the collection log:

Any hints on using this to resolve the missing symbol tables for VTune/Amplifier will be appreciated.

If need be I can run the Debug build (removing runtime checks and adding back optimization levels).

Jim Dempsey

[Ravi_N_Intel]

Jim,
   Our VTune expert is having problems logging in to respond to this thread.  Here is her response.

it seems you did not have environment variable AMPLXE_COI_DEBUG_SUPPORT=TRUE  set, so missing the offload symbols.   And many other warnings on symbol location are related to the files in the card site, not for offload app.  If that is part of user’s interests,  please locate them in the host location if possible, and add the path  into the search directory in the Vtune project property screen. 

[jimdempseyatthecove]

Ravi,

That environment variable was (and is) set to TRUE.

At this time, I am not interested in having VTune locate the Intel supplied libraries (this may come later).

What I am interested in is that it locates the debug information for my produced code (and debug symbols) for the MIC offload side of a Fortran generated .DLL. This would be the

/!\ Cannot locate file '/var/volatile/tmp/coi_procs/1/6522/load_lib/47922618MIC.out'

And possibly

/!\ Cannot locate debugging symbols for file `'

whatever that is.

MPSS and Parallel Studio are installed into their default locations (on Windows 7 Pro x64).

Jim Dempsey

[jimdempseyatthecove]

Additional information:

A thought came to me that while running the offload program, I should search the HD for the location of the *MIC.out file. Here is what I found

C:\Users\Jim\AppData\Local\Temp\coi_procs\1\

contains a list of folders who's name appears to be the process ID and a similar named file with file type .mapping.

By adding that folder to the Binary Symbol Search list of folders, I then get the symbolic information for VTune.

The question I have for the Parallel Studio XE integration into MS VS is: seeing that the compiler can locate the path to place the *.MIC.out files, why cannot the integration of VTune also locate the correct path?

Jim Dempsey

[Kevin_D_Intel]

The placement of the *.MIC.out in the coi_procs area is function of MPSS and not the compiler's VS integration. I passed along your latest update earlier this morning to Ravi et. al. and am waiting to hear from the VTune Developer regarding your question.

[jimdempseyatthecove]

While it may not be part of VS integration per se, it should be part of VTune/MPSS integration (inside VS).

Jim Dempsey

[Kevin_D_Intel]

Turns out the compiler has a role it can play here in providing information in the offload executable to assist VTune in locating this symbol information. At Development's request I submitted a feature enhancement and will keep you updated on the progress of that.

(Internal tracking id: DPD200379487) 

[jimdempseyatthecove]

Thanks Kevin.

I also posted a new forum topic on how add a redirected console to a DLL in a non-console application to track down another fleeting offload issue. The error showed up (past tense) when attempting an Amplifier run on a release build. (Debug build works). The error presented itself with

(X) target -
offload error: allocation (base=0000000033581E60, size=56) overlaps with existing allocation (base=000000003358E150, size=56)

This occurred prior to entry into the offloaded DLL, but I suspect during the attempt to load the offload. The odd thing about this is the same image(.exe together with .DLLs) runs outside the Amplifier with and without the debugger. When I added to code to change the AllocConsole to CreateFile and SetStdHandle (i.e. remove one line, add two lines of Fortran code), the allocation error now goes away. This may indicate a race condition. The host application is multi-threaded where many threads may be calling the offload(s) concurrently via asynchronous offload. This may indicate that the offloadmain + .so file injection code is not thread-safe for the first time offload.

*** note, the allocation error occurs _prior_ to entering the offload code generated by IVF

The Bottom-up display shows only vmlinux and libc-2.21.so. The ...MIC.out (and its dependencies) have yet to be loaded.

Jim Dempsey

[Kevin_D_Intel]

I opened another internal tracking id per Development's request related to your comment/findings on the thread-safeness of the offload main. I'll keep you updated as I learn more.

(Internal tracking id: DPD200379555 - thread-safeness of offload initialization)