Problem with new'd object and vectorized loops

[Kris_W_]

I am currently trialling the ICL to see what improvements we can make to our software to hopefully speed it up.

I've had quite a lot of issues trying to get it to compile but eventually got there (may raise a few more topics on things I've had to disable to get it to build), it worked fine in debug but in release it crashed at what appeared to be a totally irrelevant place.

It was failing on a loop that was initializing some arrays to zero, but complaining about access violations. I eventually figured out that it must be because of vectorizing the class but it wasn't sure why as we do __declspec(align(16)) before the class so it should be correctly aligned, also we have no problems with this code when compiled with Visual Studio 2013 compiler.

I eventually found the problem in a cutdown testbed version of the code (attached)

It seems when creating an instance of the object like so then it fails:

CModel* pModel = new CModel();

If instead I create it as follows then everything works fine:

	void* ptr = _mm_malloc(sizeof(CModel), 16);
	CModel* pModel = new(ptr) CModel();

So, it's possible (likely) that my knowledge of C++ is lacking at that there is another way I am supposed to create a new instance of an object when new'ing (the class CModel actually is a base class so hence the need for pointer) but just asking for clarity as this was a real pain to try and figure out what was going wrong as the pointer was fine and the error it was throwing seemed totally irrelevant until I twigged that it must be vectorizing the loop (I've been reading up on it).

[jimdempseyatthecove]

Are you aware that you can overload operator new. You can do this globally and/or for specific class/struct objects.

See: http://www.cprogramming.com/tutorial/operator_new.html

By doing so, you can assure that CModel meets your alignment criteria.

Note, allocations of aligned arrays of objects is a little bit trickier as the block of memory for the array contains a header holding a count of the number of objects (used by operator delete[] in a loop performing operator delete). You can find information on this by searching the web.

Jim Dempsey

[Shenghong_G_Intel]

I can reproduce the issue and it looks like it only crash with ia32 compiler, it can even work for 64bit. You are correct it looks like an optimization bug (vectorization bug), it works with /Qvec-.

And the crash is inside the de-constructor (delete), removing the delete line it will work.

I will submit the case to developer to fix.

Thanks,

Shenghong

[Bernard]

>>>It seems when creating an instance of the object like so then it fails:>>>

Usually  *pModel should contain valid address of the newly created object of type CModel which is allocated on the heap. With VS debugger you can track return value from new operator which is usually loaded in ecx register.

[Bernard]

>>>you can track return value from new operator which is usually loaded in ecx register.>>>

Little correction of my quoted statement. Operator new will call Heap Allocation function which in turn will call VirtualAlloc function and usually the address of the newly alocated object will be returned in eax register(32-bit Win) which will be load into ecx register.