Another update, another Compiler error...

[Dix_Lorenz]

I am getting really tired of this; I have been working with C++ for almost 20 years and I have found bugs in almost every compiler. But the Intel compiler is by far the worst ever. So this morning I updated to the C++ 2013 Compiler for Windows Update 2, 2013.2.149, hoping for some fixes. 2 Minutes later I get a compiler crash:

2>P:\genlibs\dlcl\include\DLPersist.h(13,15): error : assertion failed: dump_type_declaration: bad type kind [error] (shared/cfe/edgglue/edg_type.c, line 433)

The line in question is approximately 15 years old: 

const DLULong MaxDLPersistID =1000;

(DLULong is a typedef to unsigned long).

Unfortunately I can't leave ICC behind until MS implements a bit more of C++11, so... How can I help you find out what the hell this bug is? Clearly this code in itself can't be problematic, not even for ICC and in any case the compiler shouldn't crash! Don't expect too much of an effort from my side on this though, I am done with ICC, it is costing far too much of my time; right now I have to deinstall it and reinstall an older version because I will not work around compiler bugs for simple code like this and obviously I also can't wait for an update which might or might not fix this.

Pretty much the only reason for this report and an offer to help you identify this bug is that I have no doubt I will find more bugs in Update 1 and at some point I might have to upgrade; who knows when VC will support the features I need.

[SergeyKostrov]

>>I am getting really tired of this; I have been working with C++ for almost 20 years and I have found bugs in almost every >>compiler. But the Intel compiler is by far the worst ever... Dix, Sorry to hear that and I will look at your test case. Thanks for reporting the problem.

[SergeyKostrov]

I wonder if Intel software engineers could verify what is going on with latest Updates ( 1, 2 and currently in progress 3 ) of the compiler. I did a verification with 32-bit and 64-bit versions of Intel C++ Compiler XE version 13.0.0.089 Build 20120731 ( Initial Release ) and I did not detect any compilation problems. My test looks like: typedef unsigned long DLUlong; const DLUlong MaxDLPersist = 1000; int main( void ) { DLUlong ulValue = MaxDLPersist; return ( int )0; } Dix, please provde a feedback on how that type is used. Does my test case looks right for you? Thanks in advance.

[Dix_Lorenz]

The compiler doesn't crash when MaxDLPersist is being used, but when it is defined and the first 2 lines are the relevant ones. Note that I didn't check if those 2 lines alone would have triggered the bug, was too busy reinstalling Update 1.

>> I did a verification with 32-bit and 64-bit versions of Intel C++ Compiler XE version 13.0.0.089 Build 20120731 ( Initial Release )

As I said: This only happened after I updated to Update 2, no other C++-Compiler ever until that one had any problem with this.

[SergeyKostrov]

>>...The compiler doesn't crash when MaxDLPersist is being used, but when it is defined and the first 2 lines are the relevant ones... This is what I wanted to hear and let's wait for a response from Intel software engineers. Unfortunately, I don't have latest Updates for the compiler on my development computer.

[SergeyKostrov]

Dix, you could be asked for a complete command line you've used and please provide it.

[Dix_Lorenz]

There is no complete command line, this is inside VS 2010. I merely updated the Compiler, started VS, opened the solution, hit "Clean" and then "Rebuild" (I know it's redundant but with VS I am rather safe than sorry) and after about 12 successfully compiled files (which btw don't compiler in parallel despite that they should; thats yet another new bug, but somebody else had already posted that) it hits the first one that includes the header where MaxDLPersistID is defined and crashes

Build settings are Debug, 64 Bit it that is any help.

[SergeyKostrov]

>>...There is no complete command line, this is inside VS 2010... A set of some C++ compiler options is always used even if it is not seen directly. To get a complete command line for C++ compiler follow these steps: - In the 'Solution Explorer' select the project where the compilation error happens - Mouse right click and select 'Properties' item ( last one at the bottom ) - Configuration Properties -> C/C++ -> Command Line -> Select all of them -> Copy into clipboard -> Post it

[Dix_Lorenz]

/I"P:\genlibs\foreign\loki\include\loki" /I"include" /I"P:\genlibs\dlcl\include" /I"P:\genlibs\dlcl\include\windows" /I"P:\genlibs\dlgl\include" /I"P:\genlibs\mmcl\include" /I"P:\genlibs\mmcl\include\windows" /I"P:\genlibs\foreign\xml" /I"P:\genlibs\foreign\xml\expat\xmlparse" /I"P:\genlibs\foreign\xml\expat\xmltok" /I"P:\genlibs\dlgl\include\windows" /I"P:\genlibs\foreign\tnt" /I"P:\genlibs\foreign\macstl" /I"P:\genlibs\foreign\macstl\impl" /I"P:\genlibs\foreign\jama" /I"P:\genlibs\foreign\windows\ChartDirector64\include" /I"P:\genlibs\foreign\utf8proc" /I"P:\genlibs\foreign\utfcpp\source" /I"..\common\dlgui\include" /I"..\common\dlgui\include\windows" /I"..\common\v_mM4\include" /I"..\common\v_mM4\include\windows" /I"..\windows\mfc\include" /I"..\windows\UltimateToolbox_V93\include" /I"..\windows\Ultimate Grid_V72\include" /Zi /nologo /W3 /MP /Od /D "MKL_NUM_THREADS=1" /D "MM4UNIVERSAL" /D "_VARIADIC_MAX=6" /D "DL_ISWINDOWS" /D "DLINCLUDESTDHEADER" /D "DLSMP" /D "NOMINMAX" /D "_DEBUG" /D "DL_ISDEBUG" /D "_UNICODE" /D "UNICODE" /D "_AFXDLL" /EHsc /RTC1 /MDd /GS /arch:SSE2 /fp:precise /Zc:wchar_t /Zc:forScope /Qstd=c++0x /Yu"DLStdInclude.h" /Fp"P:\projects\mM4\mediMACH\\temp\Debug_64\mediMACH4_Debug.pch" /Fa"P:\projects\mM4\mediMACH\\temp\Debug_64\" /Fo"P:\projects\mM4\mediMACH\\temp\Debug_64\" /Fd"P:\projects\mM4\mediMACH\\temp\Debug_64\vc100.pdb" /Qdiag-disable:"1885" 

[JenniferJ]

There is a bug fix to be compatible with MSVC related to "#define" like below. If you have code like it, it might be the reason.

#define X defined(y)
#if X { Do something … } 

With above code, VC will evaluate X with "false" even if "Y" is defined. ICL was not the same as VC, but now is.
To disable this, use /Qms0

[edited to correct the icl change]

[Dix_Lorenz]

I searched, nowhere in my code (or in code being included) that pattern is being used.

[JenniferJ]

can you attach the .i file? If not, please file a ticket to Intel Premier Support.

Jennifer

[SergeyKostrov]

I verified your command line options and I didn't see anything wrong. A typedef declaration like: typedef unsigned long { typename }; is a fundamental one and it is used in many Windows header files, SDK, libraries, etc. So, try to do a simple test: add #include "windef.h" directive in one of your source files, declare const DWORD dwVariable = 1000; and if you don't see any errors then something is wrong inside of one of your header files. I also checked Platform SDK, DirectX SDK, MFC, Speech SDK, WTL and declarations like: typedef unsigned long DWORD; or typedef unsigned long ULONG; used in many header files and I counted more than 50. It means, if somebody else downloaded Update 2, installed it and didn't report any problems then everything is fine. If you don't want to spend more time on investigation ( a reproducer is needed! ) then I don't know how somebody else could help you.

[Dix_Lorenz]

I am well aware that the line that ICC crashed on (not "that it flagged as being defective", IT CRASHED!) is extremely common and I know that my code is correct, is has been for around 15 years, through many generations of 4 completely different compilers. I know it is something else that is triggering a bug in the Compiler, that line is just where it manifests.

I also know you can't do much without a reproducer, I might try to produce a .i-file at some point; I actually have work to do and so I needed to reinstall Update 1 (which compiles without a problem). I would have to redownload the U2 and that is very slow from the Software Manager (has anybody ever filed a bug about that? I get dl speeds of about 200 KB/s or so). It goes much faster from a web browser (1-2 MB/s IIRC) but my subscription has expired recently so I can't get to that any more. I actually should renew (I was about to after I had installed Upgrade 2), but I feel very hesitant to renew software just so I can upgrade to a version which I know for a fact to be defect...

[SergeyKostrov]

>>...my code is correct, is has been for around 15 years, through many generations of 4 completely different compilers. I know it is >>something else that is triggering a bug in the Compiler, that line is just where it manifests. Nobody stated that the line is wrong. I mentioned in my previous post that something else affects the compilation process and as a result there is the crash. >>...I also know you can't do much without a reproducer, I might try to produce a .i-file at some point; I actually have work to do >>and so I needed to reinstall Update 1 (which compiles without a problem)... Please, try to book some time for investigation with Update 2 because sooner or later you could upgrade the compiler. Once again, if somebody else will report a similar problem it will be an indication of a bug in the compiler related to Update 2. >>...I would have to redownload the U2... Unfortunately, it is a well known issue and, as far as I know, Intel software engineers are working on it. Please keep everybody informed on the status of your investigation. Thanks in advance.

[SergeyKostrov]

>>... I would have to redownload the U2 and that is very slow from the Software Manager (has anybody ever filed a bug about >>that? I get dl speeds of about 200 KB/s or so)... Please take a look at: Forum Topic: Intel Software Manager Web-link: software.intel.com/en-us/forums/topic/266292 and report all problems you've experienced with Intel Software Manager. Thanks in advance.

[Dix_Lorenz]

I investigated a bit this morning, writing this down as I go along.

Started the Software Manager, turns out the compiler was still downloaded, good so far. Started full installation, replacing current one. Opened VS, opened the solution, Clean, Rebuild, as per usual it starts building single-threaded (one problem at a time)...

2>" : error : backend signals

2>  

2>icl : error #10298: problem during post processing of parallel object compilation

and stops compilation. Great, a different problem. Not the first time I see spontaneous "backend signals", but again, one problem at a time. I open the last file in the output before this error (file A from now on), compile that one, no problem. Hit "Build", seems to build normally. Stop after 30 mins, don't have time for single-threaded compile to finish. Clean, Rebuild. Same backend signal, file A. "Build" (not "rebuild" and not compiling A by itself) it continues compiling normally, without compiling that last one. The corresponding .obj-file exists, with a size of 0 though.

I can't reproduce the original compiler crash so I can't be sure, but this could well be the same file that crashed initially, happens at the same point and is the first (i think) to include the infamous 2 lines from above. Compiling the file by itself works without any problem. 

So it seems to be more a problem of the build system than the file itself. I could preprocess it, but I don't see the point since by itself it does compile without any problems. It's regular C++11, the compiling process takes up to 600MB while compiling, I checked the .tlog files and the .vxcproj, I don't see anything that would set it apart from any of the other files around there.

After a lot more probing it turns out that indeed this file is NOT the problem; it has 4.5 k lines and when I introduce an actual error at the start of the file this gets reported and compilation continues as normal. But when I introduce one near the end this error never gets reported, instead the backend signals and compilation stops.

Hypothesis: file A takes "too long" to compile (whatever that means) and that triggers some bug somewhere which is timing related. It takes a hand-stopped 16s to compile the file, the compiler takes up to 600MB doing it (might as well be memory-related). But the crash happens after just 4s of compiling, that makes little sense. Also, the previous .obj-files look normal.

At this point I am starting to wonder why it would only compile one file at a time; the crash and that might be related since its both in the build-system. I toyed around with number of parallel project builds, no difference. I changed number of parallel c++ compiles from 0 to 8, no difference. I turned /MP to NO and that made a difference: 

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\\atlmfc\include\statreg.h(805): error : access violation

   struct keymap

This error occurs while compiling A but again, if I compile it by itself, no problem.

"Rebuild" or "Clean"/"Build", A fails to compile, with /MP = YES A.obj has a size of 0, /MP = NO, no A.obj is created.

Single-File compile: A succeeds.

Clean Build until crash, then "Build": when /MP is YES A.obj stays at 0, when /MP is NO A.obj gets compiled normally and compilation continues.

Clean Build, "Cancel Build" after around 6 files (A is #12 or so), then "Build": no problems whatsoever, A compiles normally, /MP doesn't matter.

In any case, once the progress is beyond File A I haven't (today) seen any problems.

I have no more ideas what I could check here, if you have any, let me know. It "smells" timing-related but it consistently breaks at the same line in statreg.h which would rule that out. 

On a hunch (triggered by the "cancel build" test) I switched "Precompiled Header" to "Not using Precompiled Headers"... Still using only one CPU but Rebuild goes past File A without any problems and seems to continue normally.

Not sure if it's a workable workaround for me; without parallel compilation compile times are ridiculous anyway. Please consider this as a +1 to http://software.intel.com/en-us/node/365744, developing applications is hard enough without having to wait an hour for a compilation to finish...

I hope somewhere in this wall of text you can find some nugget of information that will help you to track down the bug(s).

[Dix_Lorenz]

GRRRRR. I had written a really long post detailing what I tried and so on... Somehow it didn't get posted. So here is a much shorter version:

The build system is messing up. First of all, no matter what I do ("parallel project builds", "parallel c++ compiles", /MP), it never compiles more than 1 file at a time. That's bad enough, but there is another bug which leads to my problem of the compilation crashing.

After I installed the Update again, I did not get the same error message, instead I got 

" : error : backend signals

icl : error #10298: problem during post processing of parallel object compilation

========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========

But it happened (I think) at the same file as before. This file by itself compiles without any problems, only in a clean build it crashes. More experiments lead to me switching /MP to NO; same file crashes, this time with a "real" error message:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\\atlmfc\include\statreg.h(805): error : access violation

   struct keymap

          ^

========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========

Obviously a totally bogus error message, but reproducibly at that that exact line. I did more experimenting, here's a recap:

A clean Build (doesn't matter if "Rebuild" or "Clean/Build" or "Clean/Rebuild") always crashes at this file, about half a minute after the start of the build. With MP = YES it does create a .obj-file with a size of 0 before crashing, hitting "Build" will not compile it again but continue with compilation as if it had been correctly compiled. With MP = NO a corresponding .obj-file is not created, hitting "Build" will build this file without any problems and continue normally. Compiling this file by itself never gives any problems. Doing a clean build, "Cancel Build" after around 15s, then hitting "Build" will compile everything just fine!

The problem is the precompiled header, if I set that to "Do not use precompiled header" even a clean build finishes cleanly (but of course, using only one CPU).

Hopefully you can find something in here that will lead you to fix that bug; also, please consider this as a +1 for http://software.intel.com/en-us/node/365744, compile times are horrible enough even when its using all 8 CPUs, using just 1 it's unusable really. At this point it doesn't matter if not using PCHs is a viable workaround or not, I can't work like this anyway.

[SergeyKostrov]

>>...\Microsoft Visual Studio 10.0\VC\\atlmfc\include\statreg.h(805): error : access violation >> >>struct keymap >>... I'd like to bring attention of Intel software engineers on the following piece of code: inline HKEY CRegParser::HKeyFromString(__in_z LPTSTR szToken) { struct keymap { LPCTSTR lpsz; HKEY hkey; }; static const keymap map[] = { {_T("HKCR"), HKEY_CLASSES_ROOT}, {_T("HKCU"), HKEY_CURRENT_USER}, {_T("HKLM"), HKEY_LOCAL_MACHINE}, {_T("HKU"), HKEY_USERS}, {_T("HKPD"), HKEY_PERFORMANCE_DATA}, {_T("HKDD"), HKEY_DYN_DATA}, {_T("HKCC"), HKEY_CURRENT_CONFIG}, {_T("HKEY_CLASSES_ROOT"), HKEY_CLASSES_ROOT}, {_T("HKEY_CURRENT_USER"), HKEY_CURRENT_USER}, {_T("HKEY_LOCAL_MACHINE"), HKEY_LOCAL_MACHINE}, {_T("HKEY_USERS"), HKEY_USERS}, {_T("HKEY_PERFORMANCE_DATA"), HKEY_PERFORMANCE_DATA}, {_T("HKEY_DYN_DATA"), HKEY_DYN_DATA}, {_T("HKEY_CURRENT_CONFIG"), HKEY_CURRENT_CONFIG} }; for (int i=0;i.lpsz)) return map.hkey; } return NULL; } As you can see Access Violation happens when struct keymap is declared inside of the function.

[SergeyKostrov]

>>... I had written a really long post detailing what I tried and so on... Somehow it didn't get posted... It was possibly moderated and this is Intel's response to increased activity of spammers during last a couple of weeks. Take a look at: Forum Topic: Post problem on IDZ website: Message queued for admin approval Web-link: software.intel.com/en-us/forums/topic/369744

[JenniferJ]

Sergey Kostrov wrote:

>>... I had written a really long post detailing what I tried and so on... Somehow it didn't get posted...

It was possibly moderated and this is Intel's response to increased activity of spammers during last a couple of weeks. Take a look at:

Forum Topic: Post problem on IDZ website: Message queued for admin approval
Web-link: software.intel.com/en-us/forums/topic/369744

I think Diz's long msg did get posted. I can see the long msg before the short one.

Jennifer