_Quad type

_Quad type

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,

Fichier attachéTaille
Télécharger quadtest.zip7.49 Ko
9 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

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

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.

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;

Ca you post the disassembly?

 

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.

Fichiers joints: 

Fichier attachéTaille
Télécharger quadtest.txt474 Ko
Télécharger quadtest.zip7.27 Ko
Télécharger crash.png20.5 Ko

 

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.

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

 

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

 

Connectez-vous pour laisser un commentaire.