BUG in Eigen alignment in Composer 2013

[gianni_c_]

Hi

I just want to mention a nasty bug I'm encountering with Composer 2013.

Using Eigen 3.1.1

#include <Eigen/StdVector>

std::vector<Eigen::Vector4f,Eigen::aligned_allocator<Eigen::Vector4f> > test(256);

With Composer 2013: test is getting sized 0 !!

With Composer 2011: the allocation is OK

Is there a registered bug?

Any plans for a fix?

Thanks

Gianni

[TimP]

If you don't care to give sufficient detail here, please file an issue including a reproducer through your support account at premier.intel.com.

[gianni_c_]

The full details are here: > use of well known header only library Eigen 3.1.1 from http://eigen.tuxfamily.org/index.php?title=Main_Page > use of Xe Composer 2013 integrated in VS2010 (win32 target), on Windows7/64 Compiled these 2 lines of code as mentioned (I can't really do simpler ;-)) : #include < Eigen/StdVector > std::vector < Eigen::Vector4f,Eigen::aligned_allocator< Eigen::Vector4f > > test(256); The compilation 'goes' ok, but at run time if I put a break point just after the vector allocation, I'm getting a vector size of 0 This phenomenom doesn't occur with previous versions of Intel Compiler.

[JenniferJ]

What version of Intel c++ Composer do you have? it works for me. I have Intel C++ Composer XE version 13.0. Q:\issues\U327633\stlHello>type stlHello.cpp // stlHello.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include std::vector < Eigen::Vector4f, Eigen::aligned_allocator< Eigen::Vector4f > > test(256); int _tmain(int argc, _TCHAR* argv[]) { printf("test size: %d\r\n", test.size()); return 0; } Q:\issues\U327633\stlHello>icl /O2 /I../eigen-311 /w stlhello.cpp Intel(R) C++ Compiler XE for applications running on IA-32, Version 13.0.0.087 Build 20120718 Copyright (C) 1985-2012 Intel Corporation. All rights reserved. stlhello.cpp Microsoft (R) Incremental Linker Version 10.00.40219.01 Copyright (C) Microsoft Corporation. All rights reserved. -out:stlhello.exe stlhello.obj Q:\issues\U327633\stlHello>stlhello.exe test size: 256 Q:\issues\U327633\stlHello>

[gianni_c_]

Hi Jennifer All tests done with Intel Compiler c++ 2013 - vs2010 target 32bits Intel® C++ Composer XE 2013 Integration for Microsoft Visual Studio* 2010, Version 13.0.1179.2010 I've ran different versions of the same test, as follows. The issue is that setting a debug breakpoint just after the vector allocation, the information provided by the debugger are totally fantasist... Worse than that from time to time, trying to scan the vector element ends up with a memory violation (index out of bounds) #include "stdafx.h" #include < Eigen/StdVector > int _tmain(int argc, _TCHAR* argv[]) { std::vector < Eigen::Vector4f, Eigen::aligned_allocator< Eigen::Vector4f > > test(256); printf("test size: %d\r\n", test.size()); for (int i=0; i < test.size(); ++i) { test(0) = 1.0f; } return 0; } // test 1 (1) debug compile PreprocessorDefinitions: WIN32;_DEBUG;_CONSOLE;%(PreprocessorDefinitions) at debug breakpoint before printf: (just bringing the cursor on top of test) [4080472827]({...},{...},{...},{...},{...},{...},... but then print at the console then shows: 256 (2) release compile PreprocessorDefinitions: WIN32;_NDEBUG;_CONSOLE;%(PreprocessorDefinitions) at debug breakpoint before printf: (just bringing the cursor on top of test) [4080472827]({...},{...},{...},{...},{...},{...},... but then print at the console then shows: 256 ---------------------------------------------------------------------------------------------------------------- // test 2 debug compile with option (/QxHost) PreprocessorDefinitions: WIN32;_DEBUG;_CONSOLE;%(PreprocessorDefinitions) at debug breakpoint before printf: (just bringing the cursor on top of test) [size]=0 [capacity]=4294964019 but then print at the console then shows: 256 ---------------------------------------------------------------------------------------------------------------- // test 3 debug compile with option (/QxHost) PreprocessorDefinitions: EIGEN_VECTORIZE_SSE4;WIN32;_DEBUG;_CONSOLE;%(PreprocessorDefinitions) at debug breakpoint before printf: (just bringing the cursor on top of test) [size]=0 [capacity]=4294964019 but then print at the console then shows: 256 ---------------------------------------------------------------------------------------------------------------- I do confirm that this weird behaviour doesn't show with Intel C++ Compiler XE 12.1 Don't know exactly what wrong the compiler, the debugger or the run time?

[gianni_c_]

Well in order to be sure, I completely reinstalled parallel_studio_xe_2013_novsshell_setup.exe (evaluation version) from Intel download site. My compiler version is: Intel® C++ Composer XE 2013 Integration for Microsoft Visual Studio* 2010, Version 13.0.1179.2010 package Id 2013.0.089 I'm getting exactly the previously reported behaviour. Please find attached a copy of the screen Nothing else to say... Thanks for your support. Gianni

[gianni_c_]

Digging a little bit more, it appears that if the declaration : std::vector<:VECTOR4F> > testii(256); appears inside a procedure then the issue shows up, I sense that this may be related to the fact the stuff is supposed to be aligned allocated on the stack. if the declaration is global (as per your test Jennifer), then this is ok. std::vector<:VECTOR4F> > test_out(256); // ok with Intel 2011 and Intel 2013 void proc(...) { std::vector<:VECTOR4F> > test_in(256); // not ok with 2013, ok with Intel 2011 ... }

[gianni_c_]

Any comment from an Intel Guru??? ;-) ** After a few days... I would really appreciate some comment from Intel support staff on this one for the benefit of the user community. **

[gianni_c_]

I would not like to be negative, since I have a profound respect for Intel, its strategy and outstanding products. but.... the responsiveness of Intel staff in charge of this forum appears quite selective and slow :(

[AndrewC]

Nothing to do with Eigen.... Try the same code with something as simple as... std::vector < double > test3(256); The debugger shows a crazy value for the size.. ( on Win32) However, stepping into the std::vector code shows no issues, the size() function is working exactly as it should. Assigning elements to the vector shows no problems or exceptions. I think this is simply a visual studio 2010 debugger display issue under Win32. The debugger tries to "understand" STL containers based on how they are represented in memory by Visual C++ ( not Intel C++). This may ( or may not!) be a subtle "compatibility" issue between Intel C++ 13.0 and VC++ when it comes to displaying variables. I tried am x64 version and the debugger displayed correctly.

[JenniferJ]

Sorry for the delay. There was an issue with subscription so no email notification. I'm investigating right now, will update you soon. It sounds a bug to me. Jennifer

[JenniferJ]

yes, it is a bug. I've filed a ticket to compiler team about this debug info issue. Once I heard any work-around, I'll let you know. thanks, Jennifer

[levicki]

gianni c. wrote:

Any comment from an Intel Guru???
;-)

** After a few days... I would really appreciate some comment from Intel support staff on this one for the benefit of the user community. **

If you define a function-local variable, the value is placed on the stack and it is valid while program counter (EIP) is in the scope of that function, not before, not after. When variable is global it has visibility throughout the whole program lifetime. That may be related to the issue you are seeing. Regarding response time, if you need fast answers then submit an issue with Premier Support along with a reproducible test case. This is user to user support forum with Intel engineers moderating and participating as much as they can. We all have a life outside of this forum.

[JenniferJ]

This bug is fixed. I tested it with 13.0 update3 (13.1.1.171 Build 20130313).

Jennifer

[jeff_keasler]

Just a heads up -- there were past problems (aka bugs) in the way that Eigen uses the restrict keyword on structure members.  The restrict keyword is honored by the compiler when objects are instantiated as stack variables, and the restrict keyword is not honored when objects are instantiated in a persistent scope (i.e. on the heap, or as global variables).  In other words, bugs might appear in stack allocated objects that do not appear when objects are defined globally, or through the use of a new operator.