the following preprocessed file crashes the newest XE 2013 composer on Linux (it works in 2012).
To reproduce, gunzip the attachment and invoke "icpc -std=c++0x problem.cpp"
Thanks for your test case. I'm able to reproduce the problem you reported. I've entered this issue to our problem tracking daabase. Will let you know when I have an update regarding it.
Intel Developer Support
Tools Knowledge Base: http://software.intel.com/en-us/articles/tools
are there any updates on this, or is there a way to work around the issue?
sorry to keep nagging, but this issue is currently from successfully deploying the Intel compiler for my application. Is this anything I can do the code to work around the issue, or is this something that will be fixed soon?
I wasn't notified by your new posts. Sorry. I'm sending a note to engineering team, asking for a workaround. Will get back to you once I hear from them.
I heard from engineering team. They replied that we enabled the __GXX_EXPERIMENTAL_CXX0X__ macro with the –std=c++0x option in Gnu 4.6 and 4.7 compatibility modes which enables new C++11 features like constexpr which is used in the numeric_limits class.
Could you please try disabling this macro in the command line, i.e. adding -U__GXX_EXPERIMENTAL_CXX0X__ to the command line? This should not break anything that worked before since it was implicitly disabled in icc 12.1.
it still fails with the extra parameter you suggested:
% icpc -std=c++0x -D__GXX_EXPERIMENTAL_CXX0X__ problem.cpp
src/libcore/ssemath.cpp(28): internal error: assertion failed: ensure_il_scope_exists: NULL IL scope (shared/cfe/edgcpfe/il.c, line 7439)
const __attribute__ ((aligned (16))) SSEVector SSEConstants::max = SSEVector(std::numeric_limits::max());
compilation aborted for problem.cpp (code 4)
Sorry. I should have tested it before sending it to you. I'm passing the result to engineering team.
The instructions were to *UNDEFINE* __GXX_EXPERIMENTAL_CXX0X__, not define it. However, the error remains so this isn't a work-around.
MY MISTAKE. I used a preprocessed file rather than the original source file.
If i compile the original example directly with -U__GXX_EXPERIMENTAL_CXX0X__, I don't get an error. Thus, the work-around appears to work.
Sorry for posting confusing terminal output (I had actually played with "-D" and "-U" and then posted the wrong one).
As you pointed out correctly, applying this flag to an already preprocessed file does no good, since it is obviously meant to affect the preprocessor.
After adding an #undef to my header file, everything compiles nicely. I trust that Intel will still fix the underlying C++0x-related issue eventually?
Glad to hear that the workaround is actually working. Yeah, engineering team will implement a fix for this issue.
Composer XE 2013 Update 3 contains a fix for this issue. It has been posted to Intel Registration Center. You may download it and give a try. Please do let me know in case that the problem still persists.