MIC Fortran offload linker issue on windows

[PKM]

Hi

I am in the process of migrating a Fortran application for Xeon Phi offload and I had it almost working with the v14 compiler. Compiler issues prevented me from completing the implementation, however, and now I am back to get it fully working with 15.0.1.148. The thing is that the code will now no longer link but simply produces the message: "error PRJ0019: A tool returned an error code".

I am using the latest version of parallel studio XE on windows along visual studio 2012. Any suggestions on how to proceed? Maybe someone could give me pointers on how to try and link it manually?

[Kevin_D_Intel]

Sorry to hear about the new failure. Maybe one of our xi* tools that engage during the link is failing but that's just a guess.

Any possibility you can share a build log as a starting point to maybe see what is failing?
Better would be if you could zip up the solution and share that with us. Is that possible?

[PKM]

Hi Kevin

I have attached the full content of the output folder, including the buildlog ...

Cheers,

C

[Kevin_D_Intel]

Thank you for the files. Those proved to be very helpful.

It appears there is a new defect with the xi* tools in the IPS XE 2015 Update 1 release that I will submit to Development (and update the internal tracking id below).

I reproduced the numerous undefined references when linking manually using the IPS XE 2015 Update 1 xilink command and found the link succeeds when using xilink from the previous CXE 2014 SP1 release.

While I have instructions on how to manually link using the earlier xilink, I think it is easier to place a copy of the previous xilink in the IPS XE 2015 Update 1 "bin" directory for a short-term work around.

If you have the previous release still available then save the current xilink under C:\Program Files (x86)\Intel\Composer XE 2015\bin\intel64\ to an alternative name, xilink_2015, and then place a copy of xilink from the previous CXE 2014 SP1 release into this directory.

For the CXE 2013 SP1 Update 4 release, the xilink utility is found under: C:\Program Files (x86)\Intel\Composer XE 2013 SP1.237\bin\intel64\

If you build static libraries with offload you may also need to do the same for the xilib utility.

I will submit the issue to Development and keep you updated on the status of a fix and any other work around or information. Sorry about the new issue.

(Internal Tracking id: TBD)

[PKM]

Thanks Kevin ...

I followed your suggestion and the linking no longer produces an error. However, it appears that something now goes wrong in the linking instead.

I created a new win64 Fortran project from scratch and added a dummy offload section as seen below. When running the linked exe I get the error message seen below. The exact same thing happens for my actual program. Any suggestions?

C

offload error: cannot find offload entry __offload_entry_Console8_f90_22
...Traceback continuing on host side:
Image              PC                Routine            Line        Source

LIBOFFLOAD.DLL     000007FEE59AC926  Unknown               Unknown  Unknown
LIBOFFLOAD.DLL     000007FEE599DA94  Unknown               Unknown  Unknown
LIBOFFLOAD.DLL     000007FEE599D438  Unknown               Unknown  Unknown
LIBOFFLOAD.DLL     000007FEE59C0FAE  Unknown               Unknown  Unknown
Console8.exe       000000013FE3111E  MAIN__                     22  Console8.f90

Console8.exe       000000013FE334DE  Unknown               Unknown  Unknown
Console8.exe       000000013FE3165D  Unknown               Unknown  Unknown
Console8.exe       000000013FE3178E  Unknown               Unknown  Unknown
kernel32.dll       0000000076E059ED  Unknown               Unknown  Unknown
ntdll.dll          000000007703C541  Unknown               Unknown  Unknown
offload error: process on the device 0 unexpectedly exited with code 1

    program Console8

    implicit none

    ! Variables

    ! Body of Console8
!DIR$ OFFLOAD BEGIN TARGET(mic:0)  
!DIR$ END OFFLOAD
    print *, 'Hello World'

    end program Console8

[Kevin_D_Intel]

Bummer. I reproduced that under the MSVS IDE and via the command-line so unfortunately that’s not a usable work around and so you will want to restore the original xilink. I will see whether another work around the original link failure exists and let you know.

[PKM]

Ok - thanks!

I am willing to use whatever solution that can get it working ...

C

[Kevin_D_Intel]

After digging a bit deeper I am now wondering whether all the necessary routines have been compiled appropriately for offload.

As you probably noted, there are number of compile-time warnings about  A procedure called by a procedure with the OFFLOAD:TARGET attribute must have the OFFLOAD:TARGET attribute.

I looked into the undefined references for an merror module which appears to contain a few procedures that are reported undefined in the target link. I believe the corresponding object file is mError.obj and I noted this object file does not contains an MIC image as expected since those routines are referenced from routines that are included in the target image.

Can you double check that all the routines used within offloaded code either have the OFFLOAD:TARGET attribute appearing in the source (at the point of definition) or have been compiled to flag them with the target(mic) attribute?

The /Qoffload-attribute-target : mic option (documented here) can be used to flag all global procedures and global variables within a source file with the target(mic) attribute.

[PKM]

Thanks Kevin - I managed to find a workaround based on your hints, although the root of the problem is a little subtle ...

I compiled the entire solution with /Qoffload-attribute-target : mic as a global compiler setting and found that the amount of .mod and .modmid files didn't add up. It produced 92 .mod files and only 32 .modmic files. I then turned to the command line to try and reproduce the result and it turned out the problem is related to the /MP switch. Without /MP the compiler produces the correct number of .modmic files, but without /MP only a limited number of .modmic files are generated ...

[PKM]

Turns out the next problem was no more than a few minutes away ... :-(

When running the produced exe file I get the following error, which I thought was fixed in 15.0?

The remote process indicated that the following libraries could not be loaded:
libmkl_intel_lp64.so libmkl_intel_thread.so libmkl_core.so
offload error: cannot start process on the device 0 (error code 19)

Cheers,

C

[TimP]

CK wrote:

The remote process indicated that the following libraries could not be loaded:
libmkl_intel_lp64.so libmkl_intel_thread.so libmkl_core.so
offload error: cannot start process on the device 0 (error code 19)

This would happen if you failed to source compilervars.bat before running.

[PKM]

Uploaded build log with link line ....

[PKM]

Thanks Tim - that did the trick!

But what if I want to run the executable on a machine without the compiler installed? Are there any dependency files I need to distribute along with the exe?

Cheers,

C

[TimP]

I don't know personally anyone who checked it,  but installing the redistribution package available at the compiler download site should enable your build to run without a  compiler installation or additional license.

[Kevin_D_Intel]

I have installed only the Composer Redistributable Libraries package and MPSS on a Xeon Phi™ system, shipped over offload executables built on another Xeon Phi™ system and run those successfully. I have done that for both Windows* and Linux*.

Refer to the Redistributable Libraries for Intel(R) Parallel Studio XE 2015 for C++ and Fortran Windows* article for links to the Redistribution packages and installation details for Windows*. For Linux*, refer to the Redistributable Libraries for Intel(R) Parallel Studio XE 2015 Composer Edition for C++ and Fortran Linux* article.

Thank for you the insight about /MP. I will see whether I can reproduce that issue and post again when I know more.