access violation when linking with VisualStudio 2012 binary

[Wiebke_T_]

Hi!

I compiled and linked an executable (let's call it blah) against a static library (let's call it asdf) that is built with Intel Composer XE 2013 SP1 Update 3 as well as some other static libraries that were built with Visual Studio 2012 (parameters see below).

When I execute blah, I get an access violation out of one of the libraries built with VS2012. (It is a logger library and the error only happens when something is actually printed to stdout). That library was built with the same compiler settings as blah had before its conversion to an Intel compiler solution (except for /Qvc11).

Of course the access violation does not occur when I build the same solution with the Visual Studio compiler, otherwise I wouldn't be writing this post. :)

I suspect that the binaries are somehow incompatible (the access violation happens when I jump OUT of a method that printed a log message).

Am I missing additional compiler options for vc110 compatibility?

--------------------------------------

Here are the details:

The original VS solution of blah had these compiler parameters

/MP /GS /TP /W4 /Zc:wchar_t (various include directories) /Zi /Gm- /O2 /Fd"blah.pdb" /D "WIN32" /D "_WINDOWS" /D "_SCL_SECURE_NO_WARNINGS" /D "_CRT_SECURE_NO_WARNINGS" /D "STRICT" /D "NOMINMAX" /D "_VARIADIC_MAX=10" /D "BOOST_ALL_NO_LIB" /D "__WIN32__" /D "__x86__" /D "__NT__" /D "__OSVERSION__=4" /D "NDEBUG" /D "_ITERATOR_DEBUG_LEVEL=0" /D "CMAKE_INTDIR=\"Release\"" /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /GR /Gd /MD /Fa"Release" /EHa /nologo /Fo"blah.dir\Release\" /Fp"blah.dir\Release\blah.pch"  /bigobj

and converted into an Intel compiler solution with these compiler parameters:

/MP /GS /TP /W4 /Zc:wchar_t (various include directories) /Zi /O2 /Fd"blah.pdb" /D "WIN32" /D "_WINDOWS" /D "_SCL_SECURE_NO_WARNINGS" /D "_CRT_SECURE_NO_WARNINGS" /D "STRICT" /D "NOMINMAX" /D "_VARIADIC_MAX=10" /D "BOOST_ALL_NO_LIB" /D "__WIN32__" /D "__x86__" /D "__NT__" /D "__OSVERSION__=4" /D "NDEBUG" /D "_ITERATOR_DEBUG_LEVEL=0" /D "CMAKE_INTDIR=\"Release\"" /D "_MBCS" /Zc:forScope /GR /MD /Fa"Release" /EHa /nologo /Fo"blah.dir\Release\" /Fp"blah.pch"  /bigobj  /Qvc11

Here are the linker parameters for blah (they don't change when converting to an Intel C++ solution). Only asdf.lib was built with the Intel compiler as well, all other libs (foo?.lib) were built with Visual Studio 2012. The access violation happens in "badlibrary.lib". (I changed all the names of our own libraries):

/OUT:"blah.exe" /MANIFEST /NXCOMPAT /PDB:"blah.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "comdlg32.lib" "advapi32.lib" "asdf.lib" "badlibrary.lib" "foo0.lib" "gtest.lib" "gtest_main.lib" "chemicaltools.lib" "foo1.lib" "libboost_chrono-vc110-mt-1_55.lib" "foo2.lib" "bdal-sysutils.lib" "foo3.lib" "foo4.lib" "libboost_thread-vc110-mt-1_55.lib" "libboost_date_time-vc110-mt-1_55.lib" "libboost_filesystem-vc110-mt-1_55.lib" "libboost_regex-vc110-mt-1_55.lib" "mkl_intel_lp64.lib" "libboost_system-vc110-mt-1_55.lib" "mkl_sequential.lib" "mkl_core.lib" /STACK:"10000000" /IMPLIB:"blah.lib" /DEBUG /MACHINE:X64 /OPT:REF /INCREMENTAL:NO /PGD:"blah.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"blah.exe.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:(various lib paths) /TLBID:1

[Bernard]

I meant compiler options.

Anyway I will try to reproduce access violation error without compiling boost.

[Bernard]

While compiling I received this error "TRACKER : error TRK0002: Failed to execute command: ""C:\Program Files (x86)\Intel\Composer XE 2013".

Do you know workaround for this kind of error?

[Wiebke_T_]

No, but it seems that the icc Visual Studio integration is somehow broken. The command should be something like ""C:\Program Files (x86)\Intel\Composer XE 2013 SP1\bin\Intel64\xilink.exe". In your case it tries to execute a path.. .

Do you have composer SP1 installed? Maybe you cannot reproduce the error because you use a different compiler version.

[Bernard]

I have found workaround submitted by @Jenifer J (Intel) I will apply this workaround later today.

[Wiebke_T_]

Any news on this issue? If there is a workaround, it may be helpful for us (and bring us a big step further towards actually using the intel compiler for productive work).

[Bernard]

I will try to reproduce that error in wednesday.

Sorry for long delay I was  very busy.

[Wiebke_T_]

*bump*

We'd really like to use icc for production code... ^.^

[Sukruth_H_Intel · Accepted solution]

Hi wiebke,

                I have escalated this issue to our engineering team. But i would recommend you to lodge this issue in IPS (Intel Premier Support) for better tracking.

Regards,

Sukruth H V

[Wiebke_T_]

In Composer XE 2013 SP1 Update 5 (2013.1.5.239) this is fixed, so I am closing the topic for me the issue is resolved. Thank you for forwarding it.