XE 2013 Update 1 still has many problems for us

MHlav · ‎10-23-2012

I was anxiously waiting for Update 1 because I was assured that my application would build. Given Intel's history, I should have known better.

I'm still anxiously waiting for a release that will just build my application. After submitting several code samples, you would think they would be fixed, especially when I was told they were building on internal pre-release versions. How can something that would not build on the original XE 2013 release, but build on an internal pre-Update 1 release again not build when the update is actually released except for zero quality control? How can Intel let that happen?

I was in better shape with XE 2011--at least I could build (although there are other problems with it). I would go back, but I need to move to VS2012. I guess we’re just going to have to delay that for some time.

Does anyone else recommend any other alternative vendors with similar math/vectorization capabilities? Does AMD have a similar product?

JenniferJ · ‎10-23-2012

Hi Michael, Actually 3 of the 4 issues you reported recently are fixed in the update1, and the other one has a work-around. could you make sure you're using the latest compiler update1? Just open the Command Build Prompt from Start > All Programs > Intel Parallel Studio XE 2013 > Command Prompt > IA32 VC2010 Mode and type >> icl Intel(R) C++ Compiler XE for applications running on IA-32, Version 13.0.1.119 Build 20121008 thanks, Jennifer

SergeyKostrov · ‎10-23-2012

Hi Michael, I've just checked your User's Contribution web-page and I see only three posts: - 'XE 2013 Update 1 still has many problems for us' - 5 hours 59 min ago - 'Unchanged files always being recompiled in Composer XE 2013' - 1 month 5 days ago - 'Where do I go to download the latest version' - 1 month 3 weeks ago My questions are as follows: - What problems are you talking about? ( in your latest post ) - Could you be more specific, please? Intel Software Engineers and community members should have as much as possible technical details in order to help you. Sorry, but when you make lots of negative statements without providing any technical details and asking questions not related to your problems it is impossible to understand what is wrong. Best regards, Sergey

MHlav · ‎10-24-2012

Most of the issues have been reported as support cases instead of forum posts. As discovered after Jennifer's post, the problem that actually affects most of our code is still there. This is probably the worst problem: icl : error #10298: problem during post processing of parallel object compilation which occurs on several files for me--sometimes different between x86 and x64 builds. It was fixed in their internal build, but introduced again in the update. I still have the IDE building unecessary files. When your solution is on the order of 2000 cpp files alone (plus headers and others), this wastes time. Other problems include vectorization issues with Cilk crashing the compiler and our workaround is to unvectorize the loop. Further, warning (377) is now being issued for valid ISO standard code. This can be disabled as a workaround.

JenniferJ · ‎10-24-2012

Yes, it turns out that one issue was not showing with an intermediate compiler but is showing up with update1. There are several work-arounds, but it has been reported to the compiler team. It's been investigated as we speak. About the IDE building un-necessary files, at least one case is fixed. could you attach a testcase? or send to Premier Support. thanks, Jennifer

MHlav · ‎10-25-2012

Precompiled headers are on. This is a partial rebuild of what's previously been built. If I being the solution, then immediately rebuild it without changing anything, several of the files are recompiled. Doesn't happen if I change the projects to VC++. The vectorization issue is in the compiler.

SergeyKostrov · ‎10-25-2012

>>I still have the IDE building unecessary files. When your solution is on the order of 2000 cpp files alone (plus headers and others), this wastes time... - You need to verify that 'Use Precompiled Header (/Yu)' option is Not turned off for these files. I hope you know that 'Use Precompiled Header (/Yu)' option could be set for a project or for individual project files. I know when it is off it really slows down compilation. - Another tip, check dates for these files ( Created, Modified ). If you use some Version Control software different date/time related issues sometimes occur. >>Other problems include vectorization issues with Cilk crashing the compiler and our workaround is to unvectorize the loop. Is that a problem with Intel C++ compiler or with Cilk?

SergeyKostrov · ‎10-25-2012

>>...If I being the solution, then immediately rebuild it without changing anything, several of the files are recompiled Do you use any machine generated COM wrappers ( related to files with extensions *.IDL or *.ODL )? This is how a comment in some header file looks like: ... #pragma once // Machine generated IDispatch wrapper Class(es) created by Microsoft Visual C++ // NOTE: Do not modify the contents of this file. If this Class is regenerated by // Microsoft Visual C++, your modifications will be overwritten. ...

MHlav · ‎10-25-2012

My choice of words was not totally accurate. I'm not "rebuilding" it I'm performing a "build" once again. Yes, we have IDL files of our own as well as generated tlh/tli files. Turning on detailed output from MSBUILD gives the following reasons for building the files: aaa.cpp will be compiled as it was not found in the tracking log. and many more for other cpp files.

SergeyKostrov · ‎10-25-2012

>>...Yes, we have IDL files of our own as well as generated tlh/tli files... Could you verify modification dates / times for these h- and cpp-files between builds? Could it be the cause of your re-compilation problems? On some project that uses lots of Microsoft MapPoint COM-interfaces I've pre-created all machine generated files, set them read-only attribute, included to the project and I know that these files will be never changed.

MHlav · ‎10-25-2012

We already do that as well for most of the components we use except our own idl files which may change from time to time. We check those into version control so we have some control over the versions of those components used to build our app.

SergeyKostrov · ‎10-26-2012

>>...We already do that as well for most of the components we use except our own idl files... What happens if you do a 'Re-build ALL' and than, without any modifications in sources, 'Build'?

MHlav · ‎10-26-2012

Same issue occurs.

SergeyKostrov · ‎10-28-2012

Could you turn on VS Build Diagnostic? Follow: VS -> Menu -> Tools -> Options -> Project and Solutions -> Build and Run and for 'MSBuild project build output verbosity' try 'Detailed' or 'Diagnostic'.