Another update, another Compiler error...

Another update, another Compiler error...

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.

publicaciones de 30 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

>>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.

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.

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.

>>...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.

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

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.

>>...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

/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" 

Imagen de Jennifer J. (Intel)

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]

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

Imagen de Jennifer J. (Intel)

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

Jennifer

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.

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...

>>...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.

>>... 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.

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).

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.

>>...\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;iAccess Violation happens when struct keymap is declared inside of the function.

>>... 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

Imagen de Jennifer J. (Intel)

Cita:

Sergey Kostrov escribió:

>>... 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

>>...
>>[ skipped ]
>>...
>>...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)...

These are very good descriptions and, no matter what is going on with the build ( I understand that it takes your time! ), let's be positive. Every time when a user of some software reports a problem and the problem is fixed some time later it improves the overall quality of the software product.

And, as a software developer with significant experience, I say that your statement '...Intel compiler is by far the worst ever...' is inappropriate.

You might think it's inappropriate, as a software developer with significant experience it is (from my POV) subjectively very much true. It is actually quite tame given how frustrated I am with ICL.

I can deal with correct code failing to compile, I can narrow it down and then find some workaround (http://software.intel.com/en-us/forums/topic/279809). I can deal with a compiler having problems supporting new and exciting stuff, I just don't use it until the support is good enough (http://software.intel.com/en-us/forums/topic/326717).

I cannot deal with a compiler creating an Application that fails at runtime: http://software.intel.com/en-us/forums/topic/278487http://software.intel.com/en-us/forums/topic/356353 (I didn't post in this one, but I ran into it) and another I didn't even bother reporting because there was no way I would find a reproducible case.

All the reported ones have been confirmed as actual bugs in the compiler.

I cannot deal with the build system randomly (!) having compile errors, my automated build from the commandline sometimes works, sometimes not. Again, not much point in reporting, impossible to recreate offsite.

I found these in just one year of using ICL; I am eagerly awaiting every update, hoping that it will get better. 2 months ago I bought VS 2012 to test if I can migrate my Application: http://software.intel.com/en-us/forums/topic/344728 -> Unusable for me, had to revert back to VS 2010 and hope for an update of ICL. That's a workday (and $1K) down the drain. Now there is an update for ICL and even VS 2010 is broken for me now (another day gone between an hour-long download, bug hunting and reporting), with at least one equal symptom: single-threaded compilation. Maybe if I installed VS 2012 *and* ICC Update 2 it would work for me? It's installing as I write this, my hopes are not high (http://software.intel.com/en-us/node/365744 mentions both VS 2010 and VS2012).

I don't intend to start a flamewar, this is an objective recap of my first year (!) of working with ICL.

Visual Studio 2012 + ICL Update 2: Compiles normally... by which I mean it doesn't crash; of course it only uses one CPU, see http://software.intel.com/en-us/node/365744.

Imagen de Jennifer J. (Intel)

Cita:

Dix Lorenz escribió:

Visual Studio 2012 + ICL Update 2: Compiles normally... by which I mean it doesn't crash; of course it only uses one CPU, see http://software.intel.com/en-us/node/365744.

you mean the issue in the original post does not occure any more? could you let me know the differences of those two env? 

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)

Yes, on my first try VS 2012 did compile through without crashing. By now I have seen the second issue though

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

At the moment I avoid working on Windows as much as I can, luckily I can do most of my work on OSX; I have seen this error only once and it wasn't even a rebuild. It seems to be the same issue at heart, just not as reproducible as under VS2010.

Both environments are very much the same; VS2010 is running in a VM and since I had already tested that VS 2012 isn't yet usable for me with ICL (http://software.intel.com/en-us/forums/topic/344728) I copied the VM, installed VS 2012 (I think some November Update for this too) and ICL Update 2 to see if that would be a workable solution. I haven't actually checked if the unwanted recompiles are still there, but as long as compilation is singlethreaded it's not workable anyway.

ICL Update 2 + VS 2010: singlethreaded compilation, reproducibly crashing rebuild (with a different symptom after reinstalling ICL completely)

ICL Update 2 + VS 2012: singlethreaded compilation, sporadically crashing build

Yet another nugget: I just started up the VS2010 VM again, updated my code and now VS 2010 behaves like VS 2012; singlethreaded compilation, but compiles to the end, even when rebuilding. So my assumption that compilation under VS2012 only sporadically crashes might have more to do with some shuffling around done in my code than it actually working "better".

So Update 3 is out... I tried downloading it, but I couldn't; my sub had expired and the trial I had used for Update 2 (no point in renewing a product which is broken for me) had also expired. Did some soulsearching, decided that at some point Intel has to get things right and I should renew.

That only took 1 hour ("existing account" -> "wrong login", "forgot password" -> "no acount with this email exists", "new account" -> "an account with this email already exists, here, let me hang your browser for you"... I wish I was making that up), then only 14h until approved and another hour to download (300 KB/s is better than the 200 KB/s from before, so there's improvement)... 

That said, my code compiled without crashing (in VS 2010 as well as from the command line), once I turned /MP back on it even compiled in parallel. I haven't tried VS 2012 yet but I am cautiously optimistic, the build system has definitely improved.

>>...So Update 3 is out... I tried downloading it, but I couldn't; my sub had expired and the trial I had used for Update 2
>>(no point in renewing a product which is broken for me) had also expired...

Take into account that if you decide to try Update 3 you could request an evaluation version of Intel Parallel Studio XE 2013 ( Initial Release ) and a new license file ( you should receive it an email from Intel ) will give you another 30 days for evaluation and tests.

Imagen de Jennifer J. (Intel)

The bug with /MP is fixed in the update 3. 

Jennifer 

Inicie sesión para dejar un comentario.