"error_during_IPO_compilation"?

"error_during_IPO_compilation"?

Trying to add calls to a VSL quasi-random number generator to a largish existing code.

Prior to trying within the existing code, I wrote a small test program which generated sample sets of QRN's to assess the effects of various parameters, etc. After a bit of a struggle with the MKL Reference Manual, I got the test program working. To avoid path issues, I copied Modules MKL_VSL_TYPE & MKL_VSL and inserted them directly within my test program code (in a separte .f90 file). That worked fine. Straightforward once I got on top of the Manual.

However, on attempting to add very similar code into my existing program, I am getting Link errors I have never seem before. The QRN related code added to my existing program is basically the same as I used in the test program, except as indicated below. In both programs, I added the "Additional Library Directories" &
"Additional Dependencies" as per the instructions in Section 4 of the
User Guide for configuring the Development Environment (same details
added in both cases). Same versions of MKL(10.0.3.021) and IVF(10.1.019) in both cases. Of course the test program basically only had code related to QRN - the existing program is a largish, 'diverse' program. It does have some OpenMP code in it, but I have set "Process OpenMP Directives" to "Disable" (having for the moment given up trying to get OpenMP to work correctly!).

Test program example:

!Every access
status = vslnewstream( stream, brng, dimen ) !Create new stream
status = vsrnggaussian( method, stream, num, gauss, 1.0, 0.5 ) !1.0 & 0.5 convenient for displaying output
status = vsldeletestream( stream ) !Delete the stream

Existing program:

!INITIALISE (at start of run)
status = vslnewstream( stream, brng, dimen ) !Create new stream

!Numerous subsequent accesses in a different subroutine
status = vsrnggaussian( method, stream, num, gauss(:,:,1:m), 0.0, std_dev ) !std_dev computed in preceding code

Possibly significant differences?

1. Do not delete the stream because program terminates shortly after last access. Did delete the stream(s) in the test program because were testing several QRN options sequentually in each test run. Used a new stream for each different QRN option. Existing program only uses one set of QRN parameters for a given analysis.

2. Allocated array Guass(:,:,:): In test program were using the whole array each time. In existing program only fill (a varying size) part of the array each time ("m" can vary from 1 to max size allocated)

The code compiles and links without any problem in the sm
all test program. But I get the following Link errors when I attempt to compile the existing program with the MKL code added (compiled previously without problem):

Error 1 error error_during_IPO_compilation: problem during multi-file optimization compilation (code 3) Link
Error 2 error error_during_IPO_compilation: problem during multi-file optimization compilation (code 3) Link

The error messages are the same for both Debug & Release mode compiles. They mean nothing to me. Any assistance would be appreciated.

FWIW:
Compiler command line is:

/nologo /Zi /Od /module:"Debug/" /object:"Debug/" /traceback /check:bounds /libs:static /threads /dbglibs /c

Linker command line is:

/OUT:"Debug/Faults.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:Program FilesIntelMKL10.0.3.021ia32lib" /MANIFEST /MANIFESTFILE:"I:xxxxxxProgramFaultsdebugfaults.exe.intermediate.manifest" /DEBUG /PDB:"Debug/Faults.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"I:xxxxxxProgramFaultsdebugfaults.lib" mkl_c.lib libguide.lib

5 posts / novo 0
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.

OK, I see the latest update to IVF contains a bug fix that may be related to this ("Internal error with IPO and MKL library").

Unfortunately, updating to this new version seems to require a full uninstall of VSPPE if I want to retain ability to develop x64 code :-(. Will need to think that over - so far I have found little it any improvement in computation speed with x64 code (Vista64 / QX9650 cpu).

QN1: Is it likely that w_fc_p_10.1.024 will fix the problem I am experiencing?

QN2: If I update to w_fc_p_10.1.024 without re-installing VSPPE, can I do it later if I decide to produce further x64 exe's? ie. later uninstall VSPPE, then re-install VSPPE & w_fc_p_10.1.024?

OK, I took the plunge and installed the latest update (w_fc_p_10.1.024) sans un-installing VSPPE (for now at least - on reflection, it must be possible to uninstall everything later & start from scratch if it turns to custard).

Anyway, great news is that it fixed the "error_during_IPO_compilation" error & I can move forward on upgrading my program to use the QRN stuff.

[OT]
Amazing coincidence. I got email notification of the new update only ~4 hours before I first encountered the IPO / MKL bug in the compiler. It never occurred to me that I might have hit a compiler bug. Had almost finished writing my first post when I recalled seeing the update notification come through a few hours earlier. Thought I had better have the latest version installed before posting & was most surprised to find that the first listed bug fix was the one I just hit. Initially was thrown by the potential need to uninstall everything, including VSPPE, though.

David,

This comes a bit late for you, but perhaps other readers will benefit. The problem youre seeing is most likely a limitation of our compatibility libraries (or dummy libraries as theyre listed in our documentation). More information on this can be found here:

http://www.intel.com/support/performancetools/sb/CS-028971.htm

It sounds like the compiler has a fix now to address the limitation, but theres also a workaround. The workaround is to link against the new libraries (introduced in version 10.0) rather than the dummy libraries. So for example, you could make the following conversion:

mkl_c.lib => mkl_intel_c.lib mkl_intel_thread.lib mkl_core.lib

Todd

Thanks Todd.

It was fortunate the update come out just when I needed it.

After a while I realised it was still Sunday or pre-dawn Monday in most of the world, so I had to take a chance & push on or lose another day before having any hope of resolution.

Deixar um comentário

Faça login para adicionar um comentário. Não é membro? Inscreva-se hoje mesmo!