- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am using Intel C++ compiler XE 13 with Visual Studio 2012 (or 2010). I created a very simple console application (see attached file) to test the _Quad type using the compiler option "-Qoption,cpp,--extended_float_type". The following is all the code.
int _tmain(int argc, _TCHAR* argv[])
{
_Quad* p = new _Quad[1];
p[0] = 1.1;
delete []p;
return 0;
}
When I run the application in release mode (without using debugger), the program crashes (although it may not crash on the first try, but on the thrid or fourth try). Can anybody repeat this behavior? The crash does not happen if I use stack memory instead of free store.
Thanks,
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I built your (slightly modified) testcase with icpc 14.0 on Linux. No segfaults, cannot reproduce behavior.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, Casey. I am using Visual Studio 2012 and 2010 on Windows 8, with Intel C++ XE 13 evaluation version. The crash happens on consistently on release mode for this simplest code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is been confirmed by Intel Support that it is a bug. The following code works for 64-bit application but not for 32-bit application on Windows. It is a real suprise to me.
_Quad* p = new _Quad[1];
p[0] = 1.1;
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ca you post the disassembly?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can reproduce this with our latest development compiler. i have entered this in our internal bug tracking database as DPD200248294. Thank you for reporting this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think Intel should put a hot fix soon as this is such a basic stuff for a compiler.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for being patient with this problem.
This is caused by an unfortunate combination of two standard behaviors:
1) The Microsoft runtime does not guarantee alignment of dynamically allocated data to 128-bit boundaries
2) The compiler assumes that any pointers to standard data types, are aligned to the size of the type. With the extended-float option given, _Quad is treated as a standard type.
The compiler generates an SSE movaps instruction to assign the data to the _Quad type, which causes an alignment crash if new doesn't give an aligned address. This is why the program doesn't crash all the time.
Can you please try:
#include <aligned_new>
at the top of the program?
This automatically replaces all operator new calls with an aligned version.
If this doesn't work, the alternative is to use _aligned_malloc instead of new:
_Quad* p = (_Quad*) _aligned_malloc(sizeof(_Quad),8);
or _aligned_malloc in combination with "placement new".

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page