CODEWITHSUNDEEP
c++visual-c++intelabiicc
Robin Rodricks
Robin Rodricks

Reputation: 114076

Build a .lib with the Intel C++ compiler and use with app in VC++?

I'm using VC++ 2012 to compile a solution with 2 projects. The main library is a Class Library project which simply outputs a .lib file, and the second is an Application, which uses the compiled library.

This library is used for high-performance math in my app, so I was considering switching to the Intel C++ compiler for this portion of the solution. Is it possible to build a .lib with the Intel C++ compiler, and then link to that lib from my VC++ project to finally build my app? Is this article describing what I want?

I cannot switch the app project to the Intel Compiler for legal reasons. (Although I have the source code for the app, it is compiled by the client and they use VC++, we are only the authors of the library project)

Upvotes: 1

Views: 139

Answers (1)

Peter Cordes
Peter Cordes

Reputation: 365467

ICC and MSVC++ should be ABI compatible. For C they use the same calling convention. I think ICC tries to use compatible C++ headers so types like std::vector<T> and more complex stuff match, too. Same for ICC on Linux using headers compatible with the system standard library.

I'm pretty sure ICC-compiled code can call MSVC libraries, which also requires them to agree on ABI factors. That would be something a lot of users of ICC / ICPC would have wanted to do.

I haven't tested this myself, so this is just a guess based on having looked at how ICC uses pretty much GCC or Clang headers for at least its SIMD intrinsics; I assume they do similar for other headers. And it's obviously a very useful feature for a lot of users so there's a lot of reason they'd make the effort to do it.

Fun fact: on x86-64 System V (Linux and other non-Windows), ICC-compiled code can't safely call Clang-compiled code that take narrow integer types like short or uint8_t as args: Clang assumes the caller extended them to 32-bit, which the ABI doc doesn't require. GCC does that in call sites but doesn't rely on it in callees. ICC (classic) doesn't do that. LLVM-based ICX of course does what Clang does so is compatible with GCC and Clang.

I don't know if Clang targeting Windows x64 relies on the same thing and if ICC also doesn't do it there. If so then you would potentially have problems at call sites that were supposed to truncate a wider variable as part of passing it to a non-inline function. So that's one thing to test. See my linked answer for a test case.

I don't think MSVC relies on args being extended to 32-bit, so this wouldn't be a problem for ICC/MSVC compat.

Upvotes: 0

Related Questions