Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

_Quad type

jjjforest
Beginner
909 Views

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,

0 Kudos
8 Replies
Casey
Beginner
909 Views

I built your (slightly modified) testcase with icpc 14.0 on Linux.  No segfaults, cannot reproduce behavior.

0 Kudos
jjjforest
Beginner
909 Views

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.

0 Kudos
jjjforest
Beginner
909 Views

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;

0 Kudos
Bernard
Valued Contributor I
909 Views

Ca you post the disassembly?

 

0 Kudos
jjjforest
Beginner
909 Views

Here is the debug exe (rename quadTest.txt to quadTest.exe) as well as the source code for Visual Studio 2012.  It crashes in debug mode (run without debugging).  A Intel support person can reproduce this bug.  It seems the bug happens in 32-bit app, not 64-bit app.

0 Kudos
Judith_W_Intel
Employee
909 Views

 

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.

0 Kudos
jjjforest
Beginner
909 Views

I think Intel should put a hot fix soon as this is such a basic stuff for a compiler.

0 Kudos
Chang-Sun_L_Intel
909 Views

 

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

 

0 Kudos
Reply