Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
7782 Discussions

Possible compiler bug: templated code, multiple files, multiple instruction sets


Hi all,

I believe I've found a bug with the compiler - but am willing to be proved wrong <g>.

I have a project which is set up with different object files to target different instruction sets. Each of these object files instantiates some of the same templated code with different parameters:

in template_foo.h:

template <class impl_t> class Thing


   impl_t addTwo(const impl_t& a, const impl_t& b)


     return (a+b);



in SSEImplementation.cpp:

Thing<SSEImplType> x;

in AVXImplementation.cpp:

Thing<AVXImplType> y;

... then SSEImplementation.cpp is compiled for SSE CPUs, AVXImplementation.cpp is compiled for AVX CPUs, and a dispatcher determines at runtime which one to use based on available CPU capabilities.

All has been working fine-and-dandy using MSVC++ 2015 and Xcode 6. But using the Intel compiler there's a problem.

The real files are rather more complex than the above, and instantiating the template causes quite a bit of code to be generated at compile time, including various dependent functions.

The problem seems to be that icc tries to share these between compilation units (in a reasonable attempt to keep code bloat down?) which is fine in most cases - but /not/ in cases where the supported instruction sets differ between two compilation units. So, for example, a rounding function is being generated in AVXImplementation.cpp, which generates the VROUNDSS function. Thanks to the compiler, this function ends up being reused in, and called from, SSEImplementation.cpp. Which is fine if you run the resulting code on an AVX machine, but not if you run it on an SSE machine.

It's entirely possible that at a language level the two compiler-generated functions would have the same signature (arguments, return types, sizes, alignment etc..) but nevertheless it shouldn't try to share generated functions between compilation units that are compiled for different instruction sets.



0 Kudos
0 Replies