I receive this error during compile or link time (depending on which settings I use), if I try to build a project in Release mode...either Win32 or x64. If I build in Debug mode (either platform), the build succeeds.
If I have /Qipo turned on, the linker will also generate an error #10014 (4)
This is a project in Visual Studio 2008 that generates a static library.
Version is Intel Composer XE 2011 Update 1 build 127.
If I use the Microsoft compilers, it compiles and links fine in either debug or release modes.
Reading some other threads on here, I have tried cleaning up all temp files, but no luck.
My PC has an AMD Phenom II X4 965 (3.4 GHz), 8 GB of RAM, 250+ GB free disk space, and is running Windows 7 Ultimate x64.
Ideas? Nothing I do seems to get past this problem. I am currently on an evaluation license, and this will stop my evaluation dead in its tracks if I can't get past it.
You'd probably get better turnaround if you would submit an actual reproducer, although issues on premier.intel.com may not get priority with an eval license. When you submit an issue there, you could request an extension of your eval pending problem resolution.
I suppose you should be using /Qimf-arch-consistency (if you use any math libraries), but I have no idea if that will intersect your problem. Also, I would start with /fp:source (it's there in an odd place in the VS project options) but again that's not necessarily related to your problem.
f by "reproducer" you mean a project that exhibits the problem, yes, I can do so...the code is open-source.
How do I do that?
Preferably, the reproducer is a trimmed down version of your full source -- ideally, the shortest piece of code that is sufficient to duplicate the problem, along with the commands used to build and/or information on the development configuration.
You can directly paste the code in line using the syntax highlighter (the fourth icon on the second row of the compose window), if the source is less than, say 100 lines; or, you can tar/zip the sources and attach the archive, as explained in this link:
We have a similar report in our problem-tracking database. The internal error happens when /QaxSSE3 AND /QxSSE4.1 are presentat the same time. The problem goes away when either of these options is removed. Engineering team is investigating it now.