It is MSVS 2010, version "10.0.40219.1 SP1 Rel" (from about dialog)

EDIT: It is MSVS 2010 Professional

ICC 13.0,
Intel C++ Composer XE 2013 Package ID: w_ccompxe_2013_beta.0.060
Intel C++ Composer XE 2013 beta Integration for Microsoft Visual Studio* 2010, Version 13.0.1168.2010,

Now I have noticed the bug is manifesting itself only when "/MP" switch is used, and build is cancelled, there are 4 zero-sized .obj files (probably because I have quad-core CPU).

Hello,

the test case is any project (MSVC+ICC) with like 10 .cpp files in /MP configuration running on like 4 CPU cores. :-)

Actually, I have found Visual Studio 2010 in MSVC mode (not ICC compiler, but native MSVC compiler) when it is interrupted by Ctr+Break, it will leave zero-sized .obj files of interrupted compilation of it/them. But it will detect it/them, that this/those .obj file/s have zero size, and it will recompile it/them.

IMO, there is bug in MSVC integration, and not in ICC.

IMO it would be nice, in MSVC integration mode, if ICC could detect zero-sized .obj files, and recompile them, as they are obviously unusable for linking process...

Quote:

Sergey Kostrov wrote:

Hi,

What version of Visual Studio do you use? Please clarify.

Best regards,
Sergey

Quote:

VooDooMan wrote:

ICC 13.0,
Intel C++ Composer XE 2013 Package ID: w_ccompxe_2013_beta.0.060
Intel C++ Composer XE 2013 beta Integration for Microsoft Visual Studio* 2010, Version 13.0.1168.2010,

ping? any new news? the bug is extremely easy to reproduce when you have more than 1 core/CPU's and hit Ctrl+Break. It happens all the time ->

Now I am using MSVC 2012 Ultimate under Win8 x64, ICC 13.0.1 (package number #119) and when I hit compile when using "/MP" option, there are at most 4 zero-sized .obj files (since I'm on 4-core Intel), but at least one, and sometimes zero... like a race... But most of the times, like 90% I get 3 zero-sized .obj's (not counting ipo_*.obj file, which is harmless at rebuild), which ICC will not rebuild, since it thinks, it has been already build (as the file IS present, not regarding IT HAS ZERO SIZE), a therefore linker blows into message like object file format not recognised (of course, since it is zero-sized).

ICC should test .obj's for zero-size (and rebuild them), and/or at Ctrl+Break in MSVC IDE it should correctly delete these .obj files that have been written in assumption they will be correctly compiled to the end, not to the zero-sized *.obj file at the moment of break without flushing the binary file.

Quote:

Sergey Kostrov wrote:Quoting VooDooMan
It is MSVS 2010, version "10.0.40219.1 SP1 Rel" (from about dialog)

EDIT:

It is MSVS 2010 Professional

Thanks for the update. Unfortunately, I won't be able to do anything since I don't have VS 2010 Professional Edition ( PE ).
Ioften use"Ctrl+Break" to stop compilationbut Inever experienced any problems with zero-size object files with VS 2005 PE and
VS 2008 PE.

Two workarounds are possible:

- Use Pre-Build Event
Take a look at aProject 'Properties' -> 'Configuration Properties' -> 'Build Events' -> 'Pre-Build Event'
You could use MS-DOS command 'del *.obj' directly orin a bat-file ( a correct path to a folder with object files
has to be specified )

- Clean all Intermediate files before compilation

Best regards,
Sergey

Hi Sergey,

unfortunately, your proposed solution is a workaround, not a serious solution. E.g. MSVC without ICC integration have absolutely no problems like this. And PS, I too often hit Ctrl+Break...

Quote:

Sergey Kostrov wrote:

Hi,

>>...unfortunately, your proposed solution is a workaround, not a serious solution...

I agree and it would be nice to hear from Intel Software Engineers if they managed to reproduce that problem. It seems to me so simple "Just hit Ctrl+Break" during some build and I don't understand why 'om-sachan (Intel)' requested a test-case.

Hi Sergey,

we need to wait for Intel to resolve this issue (but maybe the issue is in MSVC IDE logic)...

For very large project (200+ .h and .cpp files with more than 1 million source lines this is indeed annoying)

best,