BUG in Eigen alignment in Composer 2013

BUG in Eigen alignment in Composer 2013

Imagen de 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

publicaciones de 15 / 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 Tim Prince

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.

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

Imagen de Jennifer J. (Intel)

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>

Imagen de 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[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?

Imagen de 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

Adjuntos: 

AdjuntoTamaño
Descargar capture-intel.jpg76.21 KB
Descargar capture2.jpg69.19 KB
Imagen de gianni c.

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

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

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

Imagen de Igor Levicki

Quote:

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.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.
Imagen de vasci_

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.

Imagen de Jennifer J. (Intel)

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

Imagen de Jennifer J. (Intel)

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

Imagen de Jennifer J. (Intel)

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

Jennifer

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

Inicie sesión para dejar un comentario.