Intel C++ 2013 compatibility issue with VC++11 in <atomic>

Intel C++ 2013 compatibility issue with VC++11 in

Аватар пользователя Alex M.

the following C++ program does not compile on Intel Parallel Composer XE 2013 integrated in Visual Studio 2012 (tried on two different machines with newly setup windows 7 SP1):

#include    <atomic>
#include    <vector>

int  main(int, char* [])
{
    std::atomic_uint  ax;
    return 0;
}

the compiler generates the following error messages:

Error    1    error : invalid redeclaration of type name "std::memory_order" (declared at line 89 of "C:\Program Files (x86)\Intel\Composer XE 2013\compiler\include\stdatomic.h")    C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xatomic0.h    18
Error    2    error : "memory_order_relaxed" has already been declared in the current scope    C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xatomic0.h    19
Error    3    error : "memory_order_consume" has already been declared in the current scope    C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xatomic0.h    20
Error    4    error : "memory_order_acquire" has already been declared in the current scope    C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xatomic0.h    21
Error    5    error : "memory_order_release" has already been declared in the current scope    C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xatomic0.h    22
Error    6    error : "memory_order_acq_rel" has already been declared in the current scope    C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xatomic0.h    23
Error    7    error : "memory_order_seq_cst" has already been declared in the current scope    C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xatomic0.h    24

the issue seems to come from double definition of the memory_order enum located in an internal header <xatomic0.h> that is included by <vector> header that comes with visual C++ 11

the second definition is located in <stdatomic.h> that is previously included by <atomic> header required by intel C++ 2013 compiler (the actual header that defines this enum is <stdatomic.h> on intel C++ 2013)

to work around this problem I need to add the following preprocessor definition guard that excludes the problematic header <xatomic0.h> prior to any inclusion:

#ifdef __INTEL_COMPILER
#define     _XATOMIC0_H     //  include guard used in <xatomic0.h>
#endif // __INTEL_COMPILER

#include    <atomic>
#include    <vector>

int  main(int, char* [])
{
    std::atomic_uint  ax;
    return 0;
}

I could not find any topic regarding this issue on intel forums - so I decided to create a new topic to show this issue.

my guess is that the proper fix would require to change some internal header included by <atomic> that come with intel c++ 2013 compiler.

I hope this will be fxed as soon as possible.

I forgot to mention the compilation options - because for this issue these are not relevant:   default option with debug / release  Win32 / x64  - all reproduce this problem.

4 posts / 0 новое
Последнее сообщение
Пожалуйста, обратитесь к странице Уведомление об оптимизации для более подробной информации относительно производительности и оптимизации в программных продуктах компании Intel.
Аватар пользователя Milind Kulkarni (Intel)
Best Reply

There is already a issue in our bug-tracking database. The CQ# is DPD200234346. as in the compile error, its due to redeclaration of memory_order.
This also comes in Linux, for some gcc versions like 4.5.
many C++0x features were only added in VS2012.
once the 13.0 update comes that fixes this name-collision issue, we will let you know.

Аватар пользователя jimdempseyatthecove

Alex, I wish to commend you on an excellent problem report together with resolution. Very clear - very concise.
BTW I am not an Intel employee - just an avid forum attendee.

Jim Dempsey

www.quickthreadprogramming.com
Аватар пользователя Milind Kulkarni (Intel)

yes the commendation is well-deserved, as the issue was known and for good reason at this stage for the fix, but we were not aware of the workaround suggested by you, and it saved time trying for workaround. thanks for problem description and straight workaround.

Зарегистрируйтесь, чтобы оставить комментарий.