BUGGY Parallel Studio 2013 update 2

[gianni_c_]

Hi,

Just updated to Parallel Studio 2013 update 2 in Visual Studio 2012.

Seems ok when compile in x64 debug mode.

But major issues in x64 Release mode:

> the debugger is throwing out weird values

> the program which was working perfectly under update 1, is now getting strange numerical behaviour 

The issue looks quite similar to the one experienced just before update 1., ie the debugger giving

fantasy values....

Is this bug reported?

btw target code is Intel C++ Compiler XE 12.1 (v100) x64

And I have to mention that compilled with debug option it works ok

and compiled in release mode with plain Microsoft c++ compiler it works fine too.

Thanks for your support

Gianni

[Mark_S_Intel1]

Giani,

Thank you for the problem report.  I will try to see if I can reproduce this problem. In the mean time, if you could provide an example, or instructions on how to reproduce this issue please let me know?

Thanks,
mark

[gianni_c_]

Please find attached a small test solution that illustrates the issue.

You'll see that although it works properly if compiled in debug mode, its behaviour is completely crazy

in release mode !

again the issue shows up:

in RELEASE compile x64 with Intel C++ Compiler XE 12.1 (v100)

Intel® C++ Composer XE 2013 Update 2 Integration for Microsoft* Visual Studio* 2012, Version 13.0.1203.11

Microsoft Visual Studio 2012 Ultimate version 11.0.51106.01 update 1

gianni

[gianni_c_]

Solved thanks to Georg,

Apparently a misplaced #pragma ivdep was the culprit!

thks

[Mark_S_Intel1]

Thank you for the update giani.  And thanks to Georg for root causing and solving the problem.  I'm providing the link here to the details in case other people run into this issue, and list Georg's response below.

"the problem you reported is neither a compiler nor debugger issue. The result is intended.

Rationale: You used IVDEP pragma which makes the compiler ignore assumed dependencies. This usually has benefits in cases were those assumed dependencies never hold during runtime. The compiler can apply more aggressive optimizations. In your case, however, assumed dependencies hold, which are accesses to array "hist". There can be multiple loop iterations writing to the same element of that array. With the IVDEP pragma you had indicated the compiler that multiple accesses can not happen, which is wrong.

If you use this pragma (also applies to SIMD pragma) you have to always verify your code. You apparently did so and proved not to use that pragma for your algorithm."