mcpcom automatically deletes files, WTF?!

[mtlroom]

Suddenly, one my project has gone crazy. Intel compiler can't compile it.
It has like 100 c and a couple of c++ files and output folder always contains only 24-25 files (obj for only some files). As if there were not enough space for other obj files. But I have enought space. While it compiles project, I see these obj files appear briefly and then disappear from the obj folder. I have no antivirus at all. I deleted all output foldes and removed all project tmp files (ncb, suo etc). I tried to move the project folder, I tried to move it to different phisical HD, still the same problem: obj files simply dissapear. I tried to reboot... nothing helps. If i try to compile manually c files separately for which obj files disapear then they compile fine, but if I compile entire project then these files disapear.

I tried everything that I could possibly try, and all I see is that for some reason intel compiler does not behave properly: it deletes output objects by itself.

I used process monitor and it was obvious that mcpcom.exe creates, writes and closes obj file and right after that it re-opens it, and deletes it. I wasted hours to find out what's wrong. The problems apears to be related to symbol versioning using gnu asm syntax. Intel compiler accepts it and doens't complain, but then it reopens the obj file and deletes it... AND THEN IT WALKS ENTIRE output dir and deletes almost all other obj files. How it decides what to delete and what not is strange; but there is definetely some algo: it always deletes all but 24 obj files

WTF?! seriously, I can't find a better word for that behaviour.

Here's symbol versioning: http://gcc.gnu.org/wiki/SymbolVersioning
I use ICL XE update 11 build 344 on win7x64

[mtlroom]

[cpp]

int test_0();

//__asm__(".symver test,test_0@VER_0");
int test(void)
{
    return test_0();
}
[/cpp]

icl.exe -nologo -Fosymver.o -c symver.c && echo OK

uncomment the __asm__ part and you'll still get OK, but the object file isn't generated (or it's generated and deleted right after it's created).

[Georg_Z_Intel]

Hello,

symbol versioning only works with ELF binaries. On Windows* our compiler only generates the typical Windows* PE binaries. AFAIK they don't have support for what you're trying to do.

Nevertheless our compiler should print an error instead of silently bailing out. I've assigned a defect to engineering (DPD200235435).

Depending on your requirements you might want to drop symbol versioning. Esp. if you're creating binaries that have to run outside a Cygwin/MinGW environment their format should be PE anyways; and there's no symbol versioning support.

Best regards,

Georg Zitzlsberger

[mtlroom]

Hi Georg, I know that. I didn't try to do symversioning on PE. The code that I'm working with is cross platform and symver simply slipped through from linux part and I started to see weird behavior. It took me like 5 hours moving code, removing antivirus, cleaning up harddrive and only after using procmon I saw that the problem was with the compiler and I started to look into what files make that problem.

[jimdempseyatthecove]

mtlroom,

I haven't used Intel C/C++ on Linux (yet). However, on Windows the default settings are for multi-file IPO (interprocedural optimizations). When in multi-file optimization "entities" are inserted into the object file by the compiler, the linker is sent the set of object files, when it notices these "entities" and submits them back to the compiler for an additional level of optimizations. What I do not know is, after the linker submits these objects back to the compiler, if an error occures at this point, are the object files in error deleted or not? (IOW it deleted the files but failed to report compilation error message.)

You could check this out, if you have an option for multi-file IPO then disable it.

Jim Dempsey

[Georg_Z_Intel]

Hello,

the problem is not related to IPO. Even if turned off the object files are not created - provided they contain any in-line assembler statement outside a function body.

I understand that this problem is quite problematic and we're working on an improvement. Hence, I'll follow up as I learn more.

Best regards,

Georg Zitzlsberger