XE 2013 Update 1 still has many problems for us

XE 2013 Update 1 still has many problems for us

Imagen de Michael Hlavinka

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?

publicaciones de 14 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de Jennifer J. (Intel)

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

Imagen de Sergey Kostrov

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

Imagen de Michael Hlavinka

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.

Imagen de Jennifer J. (Intel)

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

Imagen de Sergey Kostrov

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

Imagen de Michael Hlavinka

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.

Imagen de Sergey Kostrov

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

Imagen de Michael Hlavinka

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.

Imagen de Sergey Kostrov

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

Imagen de Michael Hlavinka

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.

Imagen de Sergey Kostrov

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

Imagen de Michael Hlavinka

Same issue occurs.

Imagen de Sergey Kostrov

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

Inicie sesión para dejar un comentario.