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.

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[i](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?

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

Digging a little bit more, it appears that if the declaration :

std::vector > 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 > test_out(256); // ok with Intel 2011 and Intel 2013

void proc(...) {

std::vector > test_in(256); // not ok with 2013, ok with Intel 2011
...
}

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

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 :(